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DECLARATION  OF  ACCORD 


1 .  PURPOSE 


This  catalog  provides  information  on  the  primary  war  games, 
combat  simulations  and  training  games  used  by  ABCA  Armies  to 
support  Studies  and  Analyses  or  drive  Command  Post  Exercises  (CPXs) 
and  Field  Training  Exercises  (FTXs).  It  is  intended  to  facilitate 
the  exchange  of  informat i'~>n  by  describing  heie  key  features  of 
Cuiicat  combat  modeling  techniques.  More  detailed  documentation 
is  available  from  the  designated  Point  of  Contact. 

2 .  SCOPE 


The  types  of  combat  models  considered  include  both  functional 
area  models  and  force  level  models.  Functional  area  models  are 
primarily  one-sided  and  focus  on  the  detailed  aspects  of  a 
particular  battlefield  functional  system,  such  as  the  divisional 
field  artillery  system.  Force  level  models  are  two-sided  and 
attempt  to  represent  all  or  most  combined  arms  and  support 
functions  at  a  given  echelon  such  as  division  and  below.  Force 
level  models  may  be  interactive  with  players  performing  various 
command,  control,  and  staff  functions  or  may  be  systemic  (totally 
computerized)  with  algorithms  usea  to  simulate  Command  decision 
logic.  Some  interactive  combat  models  (wargames)  are  used  for 
research  purposes  to  assess  potential  value  of  new  tactics  and  new 
weapon  systems  and  other  interactive  combat  models  (training  games) 
are  used  to  train  Commanders  or  to  drive  field  training  exercises. 
Force  level  systemic  models  (combat  simulations)  are  used  typically 
to  investigate  weapon  system  alternatives  or  force  structure 
tradeoffs  when  the  number  of  cases  of  interest  exceed  th^ 
responsiveness  capabilities  of  the  slower  research  games. 

3 .  ORGANIZATION 

Table  I  contains  an  alphabetical  index  of  combat  models  by 
acronym/ title . 

4 .  AMENDMENT 


The  contents  of  this  QAP  are  to  be  revised  when  necessary  by 
the  contributing  Armies,  to  reflect  development  in  national 
practices  and  to  maintain  its  currency. 

5 .  USE 


The  information  in  this  QAP  should  whenever  possible  be  used 
by  Armies  to  improve  the  level  of  standardization  or 
interoperability  on  primary  war  games,  combat  Simula*- *  ons  and 
training  games  used  by  ABCA  Armies. 


6 .  RELEASE 


A  statement  has  been  provided  on  the  releasability  of  each 
model.  It  should  be  noted  that  the  fact  that  a  particular  model 
is  releasable  does  not  imply  that  all  requests  for  release  will  be 
approved.  Each  release  will  be  judged  on  a  case-by-case  basis  and 
may  require  compliance  with  appropriate  configuration  control 
procedures.  Also,  release  to  contractors  may  be  prohibited. 

FOR  THE  WASHINGTON  STANDARDIZATION  OFFICERS: 


21  May  1991  J\ZV  I  ELDING 

COVJDNEL 

DIRECTOR 

PRIMARY  STANDARDIZATION  OFFICE 
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TITLE:  Achieving  a  System  Operational  Availability  Requirement 

ASOAR 

DATE  IMPLEMENTED:  1989. 

MODEL  TYPE:  Analysis. 

PROPONENT:  USA  CECOM,  Attn:  AMSEL-PL-SA,  Ft.  Monmouth,  NJ 

07703-5000 

POINT  OF  CONTACT:  Mr.  Bernard  Price,  AV  992-1222/(201)  532-1222. 

PURPOSE :  ASOAR  cost  effectively  prorates  a  system  operational 

availability  requirement  to  end  item  operational  availability 
goals.  It  determines  the  degree  of  supportability  necessary  to 
achieve  each  operational  availability  goal.  It  aiso  determines  the 
effective  reliability  and  maintainability  of  the  system  and 
effective  reliability  of  redundant  configurations. 

DESCRIPTION: 

Domain :  Applicable  to  all  weapon  systems. 

Span :  N/A. 

Environment :  N / A . 

Force  Composition:  N/A. 

Scope  of  Conflict:  N/A. 

Mission  Area:  Weapon  system  operational  availability  and 

reliability  analysis. 

Level  of  Detail  of  Processes  and  Entities:  End  items  of  weapon 
system  is  the  lowest  entity  modeled. 

CONSTRUCTION: 

Human  Participation:  Required  to  determine  configuration  of  the 
weapon  system  and  its  forward  level  support  concept. 

Time  Processing:  Static. 

Treatment  of  Randomness:  Deterministic. 


Sidedness :  One-sided. 

LIMITATIONS :  Analyzes  one  weapon  system  at  a  time. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Development  of  users 's 

manual  prior  to  model  distribution. 
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TITLE: 


Air  Defence  Optimising  Model 
C  ELOPER :  LA 2 
USER:  LA 2 

PURPOSE :  To  assist  in  the  selection  of  air  defence  mixes  and  deployment  for 

analysis  in  the  RARE  air  defence  model  (q.v.).  The  model  can  be  used  to 
identify  mixes  that  are  robust  to  changes  in  scenario  or  environment,  and  can 
be  used  to  conduct  rapid  sensitivity  analysis  on  resource  levels  or  system 
costs.  It  is  essential  in  weapon  mix  studies  as  a  means  of  eliminating 
player  variance  that  would  otherwise  dominate  results. 

GENERAL  DESCRIPTION:  The  optimising  model  is  a  linear  progamraing  model  which 

is  solved  using  the  LAMPS  computer  package.  For  a  given  scenario  or  set  of 
scenarios  the  model  will  choose  the  most  effective  mix  of  weapon  systems  and 
sites  to  defend  against  a  given  set  of  threats  subject  to  constraints  on 
money,  manpower  and  weapon  numbers.  The  primary  aim  of  the  model  is  to 
provide  a  balanced  defence  covering  all  the  given  tracks  equally  well. 
Maximising  expected  attrition  is  a  secondary  aim.  The  model  measures  air 
defence  performance  in  terms  of  potential  kills.  These  are  the  numbers  of 
kills  achieved  by  a  weapon  against  a  single  raid  of  aircraft  on  a  track 
assuming  no  target  starvation,  no  overkill  and  no  distractions.  The  potential 
kills  for  each  site  and  track  combination  are  determined  by  running  the  PARADE 
model  in  a  special  'data'  mode  and  are  used  as  coefficients  in  the  optimising 
model.  The  extent  to  which  the  mixes  and  deployments  generated  by  the 
optimising  model  really  are  the  best  depends  on  how  representative  the  input 
set?  of  available  sites  and  threat  tracks  are.  It  also  depends  on  the  extent 
to  which  the  potential  kills  can  be  translated  into  actual  kills  in  realistic 
threat  scenarios.  This  requires  that  the  selected  mixes  and  deployments  are 
subjected  to  detailed  analysis  in  the  PARADE  simulation  to  detect  and  explain 
any  weaknesses. 

COMPUTER  STATUS:  MAGIC/LAMPS  Package  is  available  on  the  VAX  8600.  In 

current  use. 

DOCUMENTATION:  D/DOAE/47/7  of  July  1986.  QVGAOR  Paper,  (Accn.  No  85698). 


2 


TITLE :  Air  Defense  Computer  Modeling  System  -  COMO  III 

DATE  IMPLEMENTED:  1986. 


MODEL  TYPE:  Analysis. 

PROPONENT :  Systems  Analysis  and  Evaluation  Office,  U.S.  Army 

Missile  Command,  Redstone  Arsenal,  AL  35898-5060. 

POINT  OF  CONTACT:  Charles  E.  Colvin,  AV  746-1333/(205)  876-1333. 

PURPOSE :  COMO  III  is  a  general-purpose  critical  event  modeling 

system  designed  for  the  writing  and  development  of  air  defense 
simulations.  It  is  used  to  evaluate  the  operational  effectiveness 
of  air  defense  weapon  systems  in  a  realistic  tactical  scenario. 
COMO  III  is  used  as  a  research  and  development  tool  and  an 
operations  support  tool. 

DESCRIPTION: 

Domain :  Land  and  air. 

Span :  Theater,  corps,  division,  battalion,  individual  fire  unit. 

Environment :  Electronic  battlefield,  digitized  terrain, 

meteorological  visibility. 

Force  Composition:  Mix  of  land-based  air  defense  weapon  systems 
and  mix  of  attacking  airborne  threat  and  tactical  missiles. 

Scope  of  Conflict:  Conventional. 

Mission  Area :  All  conventional  missions  of  an  attacking  airborne 
threat  and  tactical  missiles. 

Level  of  Detail  of  Processes  and  Entities:  Single  aircraft, 

tactical  missile  or  air  defense  fire  unit. 

CONSTRUCTION: 

Human  Participation:  Reguired  for  decisions  and  processes. 

Time  Processing:  Event-step  with  some  time-step  events. 

Treatment  of  Randomness :  Stochastic  using  both  direct  and  Monte 
Carlo  computation. 

Sidedness :  Two-sided,  asymmetric  with  one  side  nonreactive. 
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LIMITATIONS :  Initial  setup  of  game  requires  large  number  of  labor 

hours,  excessive  CPU  hours  for  large-scale  scenario,  reactive  and 
smart  ECM  not  played,  and  wild-weasel  tactics  not  simulated  for 
aircraft . 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Real-time  battlefield 

graphics  display  package. 

INPUT:  Tactical  scenario,  weapon  characteristics,  ECM,  weather 

effects,  fire  unit  deployment,  firing  doctrine,  rules  of 
engagement,  and  defended  ground  assets. 

OUTPUT:  Computer  printouts,  plots,  raw  data,  event-by-event 

summary,  multiple  replication  statistics,  and  kill  summaries. 

HARDWARE  AND  SOFTWARE: 

Computer:  CDC  7000  series,  CYBER  74,  VAX  11/700  series,  DEC 

MicroVAX,  DEC  8000  series,  GOULD,  HP  9000,  UNIVAC. 

Storage :  160K  octal  for  non-virtual  memory  computer. 

Peripherals :  1  VT100  terminal  and  1  high-speed  printer. 

Language :  FORTRAN  77. 

Documentation :  Fully  documented. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED,  but  data  bases  are  often 
classified . 

GENERAL  DATA: 

Data  Bate:  Minimum  0.5  man-year,  maximum  6  man-years. 

CPU  Time  per  Cycle:  Variable. 

Data  Output  Analysis:  Variable  depending  on  level  of  expertise 
of  analysts. 

Frequency  of  Use:  Continuously. 

Users:  TRADOC,  MICOM,  CAA,  AMSAA ,  USA  MSIC,  numerous 

contractors . 

Comments :  COMO  III  is  managed  by  the  MICOM  COMO  Model  Management 
Board . 
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DATE  IMPLEMENTED:  10/29/90 


TITLE :  Air  Defense  Simulation  System  (ADSS) 

MODEL  TYPE:  Analysis  -  Stochastic,  discrete  event  functional  area  combat 
model  of  air  defense. 

PROPONENT:  Concepts  &  Studies  Division,  Combat  Developments  Directorate, 
U.S.  Army  Air  Defense  Artillery  School,  Ft.  Bliss,  TX 

POINT  OF  CONTACT:  Mr.  Luis  Alvarez,  USAADASCH,  ATSA-CDC-M,  Ft  Bliss,  TX, 
(915)  568-1233;  Dr.  Carol  Burleson,  COLSA,  Inc.  (915)  779-5899. 

PURPOSE:  Analysis  of  the  combat  effectiveness  of  air  defense  systems, 
tactics,  and  doctrine;  and  development  of  air  defense  scenarios  and 
laydowns  over  terrain. 

DESCRIPTION :  The  ADSS  Model  computerized,  two-sided,  systemic, 
stochastic  model  for  the  analysis  of  air  defense  weapon  effectiveness  and 
air  defense  tactics,  doctrine,  and  employment /deployment.  The  model  is 
data-driven  and  allows  existing,  improved,  developmental,  and  conceptual 
air  defense  systems  to  be  simulated  by  placing  sensors,  weapons,  and 
munitions  with  a  variety  of  characteristics  cn  platforms.  Either  side  may 
use  any  system  characteristics,  tactics,  doctrine,  and  decision  rules 
which  the  model  can  simulate.  ADSS  attrits  and  models  the  functions  of 
individual  sensors,  weapons,  and  rounds.  It  is  designed  for  rapid, 
user-frendly  setup:  all  input  files  other  than  terrain  are  in  ASCII  free 
format.  Scenario  sizes  range  from  one-on-one  to  division  or  corps  slice. 
The  ADSS  Model  is  written  in  SIMSCRIPT  II. 5  and  FORTRAN  and  is  run  without 
user  interference.  It  may  be  executed  in  batch  mode.  The  color  graphics 
preprocessor  can  be  used  to  develop  flight  and  ground  movement  profiles 
and  laydowns  for  weapons,  sensors,  and  defended  assets  over  terrain 
display  with  elevations  and  feature  overlays.  Scenario  files  can  be 
ported  directly  to  the  model  as  input.  The  code  is  written  in  the  C 
language  interactive,  and  uses  hierarchies  of  menus.  Features  include: 

-  dynamic  line-of-sight  cn  DTED  Level  I  terrain  with  DFAD  feature 
overlays  for  foliage  and  obstacles 

-  ground  moment  by  AD  systems  and  defended  assets 

-  ground-to-air  and  air-to-ground  engagement 

-  decision  rules  for  target  selection,  engagement  decisions,  and  ROE 

-  dynamic  acquisition  using  integrated  CNVEO  (NVEOL)  VISPOE  models 

CONSTRUCTION:  ADSS  was  originally  developed  as  a  model  for  FAADS  weapons 
and  sensors  by  COLSA,  Inc.,  El  Paso,  TX  and  delivered  to  DCD,  USAADASCH, 
in  1988.  The  simulation  model  was  then  called  ADAsim  (Air  Defense 
Artillery  Simulation)  and  was  written  in  the  General  Simulation  System 
(GSS)  simulation  environment.  In  1989,  COLSA  completely  rewrote  the 
simulation  model  as  an  internal  IR&D  project  and  delivered  the  resulting 
model  to  DCD.  The  ADSS  Model  is  now  a  generic,  data-driven  air  defense 
model  in  SIMSCRIPT  II. 5.  The  preprocessor,  which  runs  cn  a  Silicon 
Graphics  Iris  3000  series  Workstation,  was  modified  for  consistency  with 
the  model.  The  postprocessor,  originally  in  SPSS,  is  being  rewritten  in 
FORTRAN.  COLSA  maintains  the  ADSS  and  provides  configuration  management 
for  the  current  ADSS  model,  preprocessor,  and  postprocessor  under  contract 
with  DCD,  USAADASCH.  ALAsim  (GSS)  and  the  postprocessor  in  SPSS  are 
maintained  by  DCD,  USAADASCH  and  are  no  longer  supported  by  COLSA. 

LIMITATIONS :  Runs  only  on  Silicon  Graphics  3000  Series  Workstations ; 

Does  not  move  entities  on  the  terrain  during  scenario  development;  Run  and 
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setup  time  highly  scenario  dependent;  flight  profiles  must  be 


PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  Ground-to-air  ID  module:  IFF, 

ASM,  ROE,  NCIR;  Dynamic  ECM-broadband  jamming;  New  flightpath  generator 
based  cn  BLUEMAX  and  HELIPAC  from  SUKVIAC;  New  statistical  postprocessor. 

INPUT:  Material  characteristics:  Radar  detection  par  am;  RF  emitter  and 
detector  par am  (IFF,  ESM,  etc.);  Optical/electro-optical  sensor  par am; 
Weapon  characteristics;  Platform  dimensions  &  velocities;  Munition  flyout 
data;  Jammer  par  am;  Threat  &  friendly  munition  lethalities  vs  aircraft  and 
ground  target  types;  Round- target  matrix;  Scenario  files 

OUTPUT:  For  each  replication:  Event  histories  for  selected  vehicles,  side 
event  types;  For  single  or  multiple  replications:  Detection,  tracking, 
engagement,  damage,  and  attrition  means  and  range  histograms  vs  target, 
weapon,  sensor,  and  round  types 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS) :  ADSS  Model  and  Postprocessor  -  VAX  VMS;  Preprocessor  - 
Silicon  Graphics  Iris  3000  Workstation  under  UNIX. 

STORAGE:  Currently  running  cn  DEC  VAX  3600  with  16  Mb  virtual  memory 
and  622  Mb  disk;  Silicon  Graphics  Workstations  have  two  180  Mb  disks. 

PROGRAMMING  LANGUAGE:  Model  and  Postprocessor  -  SIMSCRIPT  II. 5  and 
FORTRAN;  Preprocessor  -  C  and  SG  3000  GL  (C-based) . 

DOCUMENTATION:  User  Manual  (input  file  and  element  descriptions); 
Technical  Manual;  Executive  Surrmary;  Preprocessor  Manual;  and 
Postprocessor  Manual. 

OTHER  COMMENTS:  Large  terrain  data  files  may  result  in  unacceptably 
long  model  execution  times  during  interaction  with  preprocessor. 

SECURITY  CLASSIFICATION:  All  code  is  UNCLASSIFIED.  Databases  may  be 
classified  if  systems  can  be  identified. 

GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE:  Time  required  for  2  deg  by  2  deg  input  file  averages  3-4 
hours  of  elapsed  time  on  equipment  described  above  (varies  with  density) . 

CPU  TIME  PER  CYCLE:  1-5  minutes  per  cycle  on  the  VAX  with  a  dedicated 
system  and  FAADS  platoon  level  scenarios  with  less  than  20  aircraft. 

DATA  OUTPUT  ANALYSIS:  Highly  dependent  on  the  scenario  and  the 
analysis  at  hand.  Output  summary  displays  for  each  rep  are  easily  compared 

FREQUENCY  OF  USE:  Two  studies  using  the  ADSS  model  are  in  progress  at 
COLS  A.  Preprocessor  is  used  cn  average  of  every  2  months  for  stand-alone. 

USERS:  DCD,  USAADASCH;  COLSA,  Inc. 


COMMENTS:  None. 
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TITLE :  Air-to-Air  Infrared  Missile  Model 


ATAS 


DATE  IMPLEMENTED:  1987. 

MODEL  TYPE:  Analysis. 

PROPONENT:  Directorate  For  Systems  and  Cost  Analysis  (AMSAV-BA), 

U.S.  Army  Aviation  Systems  Command,  4300  Goodfellow  Blvd,  St  Louis, 
MO  63120-1798. 

POINT  OF  CONTACT:  William  E.  Bodden,  DSN  693-1155 

PURPOSE:  RESEARCH  &  EVALUATION  TOOL  (COURSES  OF  ACTION 

ASSESSMENT) .  Provides  a  tool  to  help  determine  safety  of  fire 
envelopes  when  launching  a  Stinger  missile  from  a  helicopter. 
Model  is  designed  to  track  the  distance  between  the  missile  and  its 
platform;  it  is  a  modification  of  MICOM's  Ground-to-Air  Infrared 
Missile  Model. 

DESCRIPTION: 

Domain :  Land  and  air. 

Span :  Individual  helicopter. 

Environment :  Sensitive  only  to  height  above  sea  level  and 

relative  location  of  ground  to  target. 

Force  Composition:  Single  helicopter 

Scope  of  Conflict:  No  conflict  involved;  target  is  passive. 

Mission  Area:  Standard  firing  of  Stinger  in  air-to-air  or 

air-to-ground  role. 

Level  of  Detail  of  Processes  and  Entities:  A  single  attacker 
aircraft  fires  a  single  Stinger  missile  against  a  passive, 
moving,  ground  or  air  target. 

CONSTRUCTION: 

Human  Participation:  None  required  or  permitted. 

Time  Processing:  Dynamic,  time  step  model. 

Treatment  of  Randomness:  Basically  deterministic. 

Sidedness :  Two-sided,  asymmetric,  one  side  non-reactive. 

LIMITATIONS :  Can  only  model  Stinger  missile;  requires  detailed 
flight  paths;  seeker  lock  cannot  be  broken  due  to  low 
signal- to-noise  ratio  or  clutter. 


PLANNED  IMPROVEMENTS /MODIFICATIONS :  Incorporation  of  aircraft  yaw, 
pitch,  and  roll  on  initial  missile  velocity;  new  roll  rate 
algorithm;  better  approach  to  downwash. 

INPUT :  Attacker  and  target  flight  paths;  relative  locations  at 

start;  downwash  data;  breakdc  .  of  attacker  aircraft  into 
cylinders;  other  attacker  geometry. 

OUTPUT :  Attacker,  target,  and  missile  parameters  for  selected  time 
steps;  miss  distances  between  platform  and  missile  and  between 
platform  and  launch  motor;  miss  distance  of  missile  to  target; 
total  missile  drop. 

HARDWARE  AND  SOFTWARE: 

Computer:  DELL  System  310  w/Bernoulli  Box  II;  uses  MS-DOS 

operating  system. 

Storage:  256K  bytes 

Peripherals :  Printer. 

Programming  Language:  FORTRAN 

Documentation :  (Basic  MICOM  missile  model)  :  Technical  Report 

RD-83-13,  Stinger  Post  Hybrid/Digital  Simulation  Implementation 
(U),  David  M.  Curry,  Victor  S.  Grimes;  Systems  Simulation  and 
Development  Directorate,  U.S.  Army  Laboratory,  U.S.  Army  Missile 
Command,  Redstone  Arsenal,  AL  35809;  August  1983  (CONFIDENTIAL); 

( AVSCOM  Modifications):  Technical  Memorandum,  Overview:  AVSCOM 
Air-to-Air  Modifications  to  MICOM  Infrared  (IR)  Ground-to-Air 
Missile  Fly-out  Simulation  Model  (Interim  Report),  Arnold  V. 
Arconati,  William  E.  Bodden;  Directorate  for  Systems  and  Cost 
Analysis,  US  Army  Aviation  Systems  Command,  4300  Goodfellow  Blvd., 
St  Louis,  MO  63120-1798  (UNCLASSIFIED). 

SECURITY  CLASSIFICATION:  CONFIDENTIAL. 

GENERAL  DATA: 

Data  Base:  Varies;  probably  averages  about  two  months  -  drivers 
are  the  flight  paths  and  the  breakdown  of  the  platform  into 
cylinders . 

CPU  Time  per  Cycle:  5-10  minutes. 

Data  Output  Analysis:  Varies;  relatively  short  time  period  since 
miss  distances  are  printed  out. 

Freguencv  of  Use:  Variable 

Users :  AVSCOM  Directorate  for  Engineering  and  Air-to-Air  Stinger 
Office . 

Comments :  All  missile  related  algorithms  are  intact  from  the 

original  MICOM  model. 
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Releasabilitv :  Only  releasable  with  the  permission  of  the 

Stinger  PM  at  MICOM. 
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TITLE :  Ammunition  Sustainability  Life  Cycle  Model  -  ASLCM 

DATE  IMPLEMENTED:  August  1987. 

MODEL  TYPE:  Analysis. 

PROPONENT :  PM  AmmoLog,  Mr.  Gary  Kent. 

POINT  OF  CONTACT:  HQ,  Army  Materiel  Command,  Attn:  AMCAM 

(Ms.  Gulledge),  5001  Eisenhower  Avenue,  Alexandria,  VA,  22333-0001, 
DSN:  284-8484/3332. 

PURPOSE :  To  provide  a  macro  management  tool  that  pinpoints 

constraints  in  the  flow  of  ammunition  from  production  to  user, 
identifies,  the  magnitude  of  the  constraints  and  parametrically 
assists  in  determining  impact  if  constraints  are  alleviated. 

DESCRIPTION :  The  ASLCM  simulates  the  flow  of  ammunition  from 

production  to  end  user.  The  simulation  includes  rates 

(expenditures,  handling,  and  production),  capacities  (storage  and 
lift  handling),  resources  (containers  and  ports,  breakbulk  and 
container  berths),  transporters  (types  and  velocities,  nodes  and 
distances),  and  entities  to  include  initial  distribution  of  assets 
and  quantities  produced  and  moved.  Simulations  are  based  on:  Flow 
doctrine,  realistic  stockage  quantities,  transportation  factors, 
port  studies  and  USAREUR  plans,  "P"  or  other  expenditure  rates, 
distance  and  container  status  data,  and  storage  and  production  base 
mobilization  estimates. 

Domain:  Land,  sea,  and  air. 

Span :  Global. 

Environment :  Transportation  sites. 

Force  Composition:  Joint  forces. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Sealift,  airlift,  rail,  and  trucks. 

Level  of  Detail  of  Processes  and  Entities: 

Entities :  Planes,  ships,  trucks,  and  railcars. 

Processes:  Movement  of  ammunition  by  all  entities. 

CONSTRUCTION: 

Human  Participation:  None  after  the  initial  startup,  however, 
is  not  interruptible  without  losing  information. 

Time  Processing:  Dynamic. 

Treatment  of  Randomness:  Stochastic,  direct  computation. 
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Sidedness :  Asymmetric,  all  sides  reactive. 


LIMITATIONS :  The  only  limitations  of  the  model  are  the  limitations 
of  the  SIMAN/CINEMA  software  programs. 

INPUT:  A  series  of  information  to  achieve  the  desired  scenario 

(user-specified  parameters).  This  information  includes:  Method 
of  shipment;  i.e.,  rail,  ship,  truck  or  air;  locations  of  shipment 
and  receipt;  theater  of  operations  (Europe,  Korea,  etc); 
requirements;  capacities;  interaction  among  nodes  in  the  movement 
doctrine;  etc. 

OUTPUT :  Outputs  can  be  in  the  form  of  bar  charts,  histograms, 

plots,  tables  of  values,  correlograms ,  confidence  intervals,  mean 
test,  moving  averages,  standard  deviation  confidence  intervals, 
one-way  analysis  of  variance  of  data,  comparison  of  estimated 
variances,  text  file  DIF  format,  and  ASCII-formatted  files. 

HARDWARE  AND  SOFTWARE: 

Computer :  IBM  or  IBM-compatible  personal  computer  with 

SIMAN/CINEMA  software. 

Peripherals :  Graphics  printer. 

Programming  Language:  SIMAN. 

Documentation :  Users  manual.  However,  the  model  is  releasable 

but  can  only  be  run  on  the  SIMAN/CINEMA  software  which  is 
proprietary  and  NOT  RELEASABLE  due  to  distribution  restrictions. 
The  outputs  are  RELEASABLE. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED  (could  become  classified 

depending  on  input  of  data). 

GENERAL  DATA: 

Time  Reguirements :  30-45  minutes. 


Data  Output  Analysis: 


30-45  minutes. 


TITLE :  Analysis  of  Force  Potential  DATE  IMPLEMENTED:  1985. 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.S.  Army  Concepts  Analysis  Agency. 

POINT  OF  CONTACT:  George  Stoll,  AV  295-5259/CM  (301)  295-5259. 

PURPOSE :  Quantify  firepower  potential  of  land  combat  forces  of 

division  size  and  larger  for  use  in  analysis  of  force  levels  and 
force  ratios.  Has  been  used  primarily  to  analyze  changes  in  total 
Army  force  potential  attributable  to  force  modernization.  Has  most 
recently  been  applied  to  analyze  changes  in  force  potential  and 
force  ratios  associated  with  various  proposed  reductions  in  weapon 
procurement  and  U.S.  and  Soviet  force  size. 

DESCRIPTION: 

Domain :  Land  combat,  limited  close  air  support. 

opan :  Division  level  combat. 

Environment :  Models  day  and  night  combat  and  clear  and 

degraded  visibility  in  the  full  range  of  combat  posture  desired 
for  a  study. 

Force  Composition:  Army. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Direct  fire  battle,  close  air  support,  indirect 
artillery . 

Level  of  Detail  of  Processes  and  Entities:  Models  individual 
weapons  in  weapon-on-weapon  engagements  through  processes  of 
detection,  direct  fire,  indirect  artillery,  and  attrition. 

CONSTRUCTION: 

Human  Participation:  Not  permitted,  model  not  interruptible. 
Time  Processing:  Static. 

Treatment  of  Randomness:  Stochastic,  Monte  Carlo. 

Sidedness :  Two-sided,  symmetric. 

LIMITATIONS :  No  representation  of  terrain  or  logistical  support 

effects . 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Major  program  underway  to 
separate  stochastic  elements  from  deterministic  elements. 
Stochastic  element  will  be  run  in  batch  process  and  put  into 
library;  deterministic  element  will  draw  from  library. 


Deterministic  element  will  be  implemented  on  microcomputer; 
stochastic  element  likely  to  remain  on  mainframe. 


INPUTS :  Unit  weapon  composition,  probability  of  kill  tables, 
sensor  characteristics,  and  scheme  of  weapon  versus  weapon 
engagement  pairings. 

OUTPUTS :  Attrition  tables,  weapon  firepower  values,  and  force 

firepower  scores. 

HARDWARE  AND  SOFTWARE: 

Computer ;  Currently  Unisys  1100  mainframe,  future 
IBM-compatible  microcomputer. 

Storage :  Currently  240,000  words. 

Peripherals :  Tape  drive,  line  printer. 

Programming  Lanc-iaac:  FORTRAN  77 

Documentation :  Operator's  and  Programmer's  Guide  to  the 

Analysis  of  Force  Potential  System  (AFPSYS). 

SECURITY  CLASSIFICATION:  Unclassified. 

GENERAL  DATA: 

Database :  2-3  months. 

CPU  time  per  cycle:  30  minutes. 

Data  Output  Analysis:  1  week. 

Freguencv  of  Use:  5-6  times  per  year. 

Users :  U.S.  Army  Concepts  Analysis  Agency. 

Releasabilitv :  Releasable. 


DATE  IMPLEMENTED:  08/15/90 


TITLE:  Armored  Battalion  Recovery  and  Maintenance  Simulation  (ARMSIM) 
Model 

MODEL  TYPE:  Analysis 

PROPONENT:  U.S.  Army  Ordnance  Center  and  School  (USAOC&S),  Aberdeen 
Proving  Ground  (APG);  Maryland  21005-5201 

POINT  OF  CONTACT:  Mr.  Brice,  ATSL-CD-CS,  AV  298-2028/2803  USAOC&S,  APG, 
Maryland  21005-5201 

PURPOSE:  Research  &  Evaluation,  Weapons  Systems,  Systems  Development  & 
Effectiveness,  Combat  Development,  Current  or  New  Doctrine. 

DESCRIPTION:  Land,  local,  typical  European  battlefield,  armored 
battalion/brigade,  conventional  &  chemical,  recovery  &  maintenance 
simulated  battle,  reliability  failure  or  combat  damage  requiring  recovery 
or  maintenance . 

CONSTRUCTION :  Human  participation  not  required,  scheduled  changes  are 
permitted,  dynamic,  event  step,  stochastic,  Monte  Carlo,  one-sided. 

LIMITATIONS :  Currently  limited  to  tanks  and  armored  maintenance 
vehicles;  could  easily  be  expanded,  e.g.,  to  add  Bradleys. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  Plan  to  add  capability  to  model 
maintenance  and  recovery  concepts  of  allies. 

INPUT:  Mean  time  between  failures/kills,  mean  recovery  time,  mean  repair 
time,  other  parameters  describing  these  distributions,  maintenance  & 
recovery  concepts  &  performance  factors,  dimensions  of  the  battlefield, 
vehicle  speed. 

OUTPUT:  Printout  of  tank  availability,  losses,  &  maintenance  &  recovery 
work  day.  Video  animation  of  the  simulated  recovery  &  maintenance 
operation.  Standard  summary  report  with  plots  and  statistically  analy^M 
data  is  available. 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS) :  IBM  compatible  386  or  286  machine  with  DOS  3.0  or 
higher.  Windows  286  or  higher. 

STORAGE:  10  Mb  hard  disk.  640  K  ram. 

PERIPHERALS:  EPSON  FX  compatible  printer. 

PROGRAMMING  LANGUAGE:  SLAMSYSTEM  1.0  or  higher.  FORTRAN  4.0  or  higher. 
DOCUMENTATION:  SLAMSYSTEM  User's  Guide. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED 
GENERAL  DATA  AND  TIME  REQUIREMENTS : 

DATABASE :  No  database 

CPU  TIME  PER  CYCLE:  Less  than  1  minuted  per  run,  plus  the  specified 
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animation  time. 


DATA  OUTPUT  ANALYSIS:  None  required. 

FREQUENCY  OF  JSE:  As  required. 

USERS :  Directorate  of  Combat  Developments,  U.S.  Army  Ordance  Center  & 
School,  APG,  MD  21005-5201 
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Title:  Army  Planning  Model 


Date  Implemented:  See  Comments 


Model  Type:  Analysis 

Proponen t :  1.  D/Army  Plans  -  for  operational  use  in  planning. 

2.  DOAE  -  for  future  OA  development. 

Point  of  Contact:  1.  D/Army  Plans,  SO/APM. 

2.  DOAE,  Technical  Advisory  Group. 

Purpose :  Brings  together  planning  framework,  Army  physical  framework  and  cost 
framework  in  a  common  model/data  base  structure  to  assist  with  development  and 
analysis  of  options  in  future  planning. 

The  operational  analysis  function  is  to  provide  a  tool  for  quickly  identifying 
and  costing  appropriate  physical  elements  of  the  Army  in  support  of 
effectiveness  studies. 

The  model  is  hierarchical  permitting  costing  at  several  levels  of  activity  and 
has  the  facility  to  represent  support  costs  either  directly  or  in  the  form  of 
overheads . 

DESCRIPTION 

Domain:  Land 
Span :  Global 
Env i ronmen  t :  N / A 

Force  Composition:  Basically  Army  regiments  and  smaller  elements  where 
appropriate  but  with  facility  to  aggregate  up  to  capability  level. 

Scope  of  Conflict :  N / A 
Mission  Area :  N / A 

Level  of  Detail  of  Processes  and  Entities:  Generally  an  Army  regiment  is  the 
building  block  to  which  assets,  costs,  and  outputs  are  attributed  for 
aggregation  to  higher  levels  and  for  attribution  of  support  costs. 

CONSTRUCTION 

Human  Participation:  Selection  of  required  facilities  via  menu  hierarchy. 

Time  Processing:  Static,  but  containing  10  years  data. 

Treatment  of  Landowners :  N/A 
Sidedness :  One-sided 

INPUT:  Annual  input  of  complete  data  base  derived  from  Long  Term  Costing.  Data 
includes  latest  ORBAT,  costs,  equipment  and  support  elements. 

OUTPUT :  A  range  of  specified  and  ad  hoc  outputs  available  generally  in  the  form 
of  a  particular  option  and  its  costs. 

HARDWARE  6.  SOFTWARE 

Computer :  DEC  VAX  under  VMS. 

Storage : 

Per i pherals : 

Programming  Language:  FORTRAN  77  and  ORACLE  RDBS 

Documentation:  Extensively  documented,  including  technical  specifications  and 
user  manuals. 

SECURITY  CLASSIFICATION:  Data  base  SECRET 

Commen t s :  Model  scheduled  for  transfer  from  DOAE  VAX  to  a  dedicated  VAX  during 
I'm.  Model  expected  operational  on  DOAE  VAX  Dec  1990. 
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TITLE :  Army  Training  Battalion  Simulation  System  -  ARTBASS 

DATE  IMPLEMENTED:  1977. 

MODEL  TYPE :  Training  and  education. 

PROPONENT :  Department  of  the  Army,  Project  Manager  for  Training 

Devices  (PM  TRADE),  12350  Research  Parkway,  Orlando,  FL 
32826-3626. 

POINT  OF  CONTACT:  J.  Baldauf,  DSN:  552-3626/(913)  684-3626. 

PURPOSE :  ARTBASS  is  a  Battalion  Command  Post  Exercise  (CPX) 

Driver.  It  is  used  primarily  to  train  Battalion  Commanders  and 
their  staffs  in  the  conduct  of  land  (deep)  battle  operations. 

DESCRIPTION: 

Domain :  Land  and  air  in  that  air  strikes  and  air  defense  are 

modeled . 

Span :  Regional:  5,000  square  kilometer  area;  accommodates 

Central  Europe,  Korean  Peninsula,  SINAI,  Ft  Irwin,  and  SW  Asia; 
other  terrain  databases  could  be  prepared. 

Environment :  Models  terrain  relief  for  LOS  and  mobility, 

weather,  time  of  day,  terrain  cultural  features  such  as  built  up 
areas  like  cities,  and  natural  and  manmade  barriers  (roads, 
rivers,  bridges,  terrain  vegetation,  minefields). 

Force  Composition:  Army  Battalion  Forces,  Blue  and  Red. 

Scope  of  Conflict:  Conventional  weapons  for  Blue  and  Red  (mid 
and  high  intensity  conflicts). 

Mission  Area:  Conventional  missions. 

Level  of  Detail  of  Processes  and  Entities:  Nominally  models  down 
to  the  Platoon  level.  Can  model  squads  and  single 

vehicles/soldiers,  model  is  more  efficient  for  smaller  number  of 
units.  Movement,  conflict  and  Combat  Damage  Assessment  (CDA) 
affect  supplies,  ammunition  and  POu  levels  for  all  entities. 
Communications  and  IEW  affects  on  communications  are  also 
modeled . 

CONSTRUCTION: 

Human  Participation:  Required  for  decisions  and  for  processes. 
Model  will  wait  for  a  decision. 

Time  Processing:  Model  is  dynamic  and  time  stepped;  ratio  of 
game  time  to  real  time  is  user  justified. 


Treatment  of  Randomness:  Model  is  stochastic  and  Monte  Carlo. 


Sidedness :  Model  is  two-sided,  but  not  quite  symmetric. 

LIMITATIONS :  ARTBASS  has  only  200  units  and  doesn't  model  air  per 
se  or  nuclear,  biological,  chemical  (NBC;  warfare. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Increase  number  of  units 
to  300  and  model  air  and  create  better  printouts. 

INPUT:  Requires  extensive  data  base  containing  information  about 

weapon  types  and  capabilities,  units,  and  terrain. 

OUTPUT:  Graphics  display  of  combat  situation  including  separate 

3  dimensional  view  of  terrain;  display  can  be  based  on  acquired 
intelligence  of  a  unit  or  on  a  ground  truck.  Reports  can  be 
generated  Ad  Hoc  during  the  game  as  well  as  afterwards  for  review. 

HARDWARE  AND  SOFTWARE: 

Computer  (OS):  ARTBASS  runs  on  a  CONCURRENT  formerly  Perkin- 
Elmer  computer  with  the  OS/32  operating  system. 

Storage:  Removable  disk  storage  has  two  300  megabytes  (MB)  at 

the  development  site  and  one  300MB  at  the  development  site  and 
at  each  of  the  nine  fielded  sites.  The  Central  Processing  Unit 
(CPU)  memory  is  sixteen  MB  at  each  site.  There  are  also  two 
tape  drives  at  1600  Bits  Per  Second  (BPS)  at  each  site. 

Peripherals :  Each  of  the  nine  fielded  and  one 

development /maintenance  sites  have  one  high  speed  printer;  six 
graphics  suites  each  including  two  color  monitors,  two 
terminals,  one  bit  pad,  one  touch  screen  monitor  and  one 
printer;  and  two  terminals. 

Programming  Language :  FORTRAN . 

Documentation :  Extensive  documentation  following  the  DoD  MIL- 

STD-1644  for  the  Post  Deployment  Software  Support  (PDSS)  effort. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED. 

GENERAL  DATA: 

Data  Base:  Usually  it  takes  a  few  man-weeks  to  update. 

CPU  Time  per  Cycle:  Depends  on  the  scenario  being  used,  for 
small  scenarios  time  can  be  as  low  as  ten  sec/cycle. 

Data  Output  Analysis:  There  are  pest  processor  reports,  but  the 
majority  of  the  analysis  is  done  manually. 

Freguencv  of  Use:  Some  sites  are  booked  to  train  for  more  than 
the  next  two  years . 

Users :  Ft.  Lewis,  Ft.  Hood,  V  Corps,  VII  Corps,  Ft.  Bragg, 

Korea,  Ft.  Carson,  Ft.  Campbell,  and  Ft.  Devens  -  fielded  sites. 
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Comments :  Managed  through  a  configuration  control  board  (CCB) . 


Releasabilitv :  Executable  code  is  available  for  release  to  the 

field  through  the  CCB. 
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TITLE :  Attack  Helicopter  Air-to-Air  Fire  Control  System  Simulation 
Modal  -  ARTOAR 

DATE  IMPLEMENTED:  1987. 

MODEL  TYPE:  Analysis. 

PROPONENTS :  U.S.  Army  Armament  Research,  Development  and 

Engineering  Center  (ARDEC),  Dover,  NJ,  and  U.S.  Army  Aviation 
Applied  Technology  Directorate  (AATD),  Ft  Eustis,  VA. 

POINT  OF  CONTACT:  Mr.  Ed  Gilsky  ( ARDC ) ,  DSN  880-7969. 

PURPOSE:  RESEARCH  &  EVALUATION  TOOL  (SYSTEMS  EFFECTIVENESS).  To 

assess  the  effectiveness  of  a  turreted  gun  system  and/or  Hydra  70 
rockets,  and  accompanying  fire  control  system,  in  one-on-one, 
non-dueling  helicopter  air-to-air  (ATA)  combat  engagements. 

DESCRIPTION: 

Domain :  Air. 

Span :  Individual  helicopter. 

Environment :  Sensitive  only  to  altitude. 

Force  Composition:  Single  Helicopter. 

Scope  of  Conflict:  No  conflict  involved;  target  is  passive. 
Mission  Area:  Any  conventional  mission. 

Level  of  Detail  of  Processes  and  Entities:  A  single  attacker 
helicopter  fires  a  turreted  gun,  or  Hydra  70  rockets,  against  a 
passive,  moving  air  target. 

CONSTRUCTION: 

Human  Participation:  None  required  or  permitted. 

Time  Processing:  Dynamic,  time-step  process. 

Treatment  of  Randomness:  Model  is  stochastic.  Sensor  error  is 
done  by  a  Monte  Carlo  technique,  final  results  by  direct 
computation . 

Sidedness :  Two-sided,  asymmetric,  one  side  non-reactive. 

LIMITATIONS :  Non-duelling;  flight  paths  not  aircraft  specific; 

requires  highly  detailed  ballistic  data  for  each  projectile  used; 
has  not  been  validated. 
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PLANNED  IMPROVEMENTS /MODIFICATIONS :  Addition  of  dueling  routine, 
and  more  tracking  filters;  improvement  of  sensor  and  turret  models, 
and  use  of  actual  flight  data. 

INPUT :  Engagement  scenario  (i.e.,  target  and  attacker  flight 

paths),  target  vulnerabilities,  sensor  measurement  errors, 
projectile  "real  world"  ballistic  data,  and  flags  for  determination 
of  sensors,  filters  and  prediction  types  to  be  used  by  attacker. 

OUTPUT:  Summary  file  of  engagement,  including  burst  probability 

of  kill  and  individual  bullet  end  game  data;  bullet-by-bullet 
flight  path  and  miss  distance  data;  detailed  sensor  and  fire 
control  equations  performance  during  the  engagement  at  a  user 
specified  time  step;  and  data  to  be  used  by  a  plot  routine  to 
graphically  study  the  performance  of  the  fire  control  equations. 

HARDWARE  AND  SOFTWARE: 

Computers :  VAX  8530,  CDC  6600,  IBM  4381,  SUN  Workstation,  and 

DELL  System  310,  w/Bernoulli  Box  II. 

Peripheral  Equipment:  Printer;  graphics  terminal  to  output 
graphs  if  requested. 

Programming  Language :  FORTRAN  77 

Documentation :  Teledyne  Systems  Company  Final  Report,  Part  I  - 

Technical,  Part  II  -  User's  Manual;  August,  1983. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED. 

GENERAL  DATA: 

Data  Base:  Four  months  to  acquire  and  structure  data  in  model 
format  and  learning  time. 

CPU  Time  Per  Cycle:  Playing  time  is  5-15  minutes  for  20 

iterations;  CPU  time  per  model  cycle  is  contained  in  the  playing 
time . 

Data  Output  Analysis:  Time  to  analyze  and  evaluate  results  is 
variable . 

Freguencv  of  Use:  Variable;  project  dependent. 

Users :  US  Army  Research,  Development  and  Engineering  Center; 

Teledyne  Systems  Co.;  McDonnell  Douglas  Helicopter  Co.;  Bell 
Helicopter  Textron,  Inc.;  Boeing  Helicopter  Company;  Sikorsky 
Aircraft  Division;  Wright-Patterson  AFB  (Aeronautical  Systems 
Division);  and  US  Army  Materiel  Systems  Analysis  Activity. 

Comments :  Current  changes  to  the  model  include  an  increased 

resolution  of  target  representation,  addition  of  several  tracking 
filters  and  a  new  projectile,  and  addition  of  more  engagement 
files . 

Releasabilitv :  Not  Releasable. 
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TITLE :  Battalion/Brigade  Simulation  -  BBS 

DATE  IMPLEMENTED:  1991. 


MODEL  TYPE:  Training  and  Education. 

PROPONENT :  U.S.  Army  Project  Manager  for  Training  Devices  (PM 

TRADE),  12350  Research  Parkway,  Orlando,  FL  32826 

POINT  OF  CONTACT:  Mr.  J.  Simons,  DSN  960-4336/Comm  (407)  380-4336. 

PURPOSE:  BBS  is  primarily  used  to  train  Brigade  and  Battalion 

commanders  and  their  staffs  in  the  exercise  of  command  and  control 
during  execution  of  Air  Land  Battle  (ALB)  operations.  The  model 
is  a  single  or  multi  echelon  Command  Post  Exercise  (CPX)  driver. 

DESCRIPTION: 

Domain:  Land  and  air. 

Span :  Accommodates  any  10,000  to  30,000  square  kilometer  land 

area.  Several  databases  are  currently  available,  others  have  been 
proposed . 

Environment :  100m  X  100m  square  based.  Models  terrain  relief 

for  LOS  and  mobility,  roads,  rivers,  barriers  and  built-up  areas 
(cities).  Models  time  of  day  and  weather. 

Force  Composition:  Army  forces,  Blue  and  Red. 

Scope  of  Conflict:  Conventional,  nuclear  and  chemical  warfare, 
both  Blue  and  Red  (mid  and  high  intensity  conflicts). 

Mission  Area:  Conventional,  nuclear  and  chemical  Air  Land 

missions . 

Level  of  Detail  of  Processes  and  Entities:  Nominally  models  down 
to  Platoon  level  for  Battalion  CPX,  down  to  Company  for  Brigade 
CPX.  Can  model  squads,  single  vehicles/soldiers  and  single 
aircraft  for  reconnaissance  or  other  special  missions,  but  model 
is  more  efficient  for  smaller  number  of  units.  Personnel  modeled 
by  MOS  for  each  entity.  Movement,  conflict  and  Combat  Damage 
Assessment  (CDA)  affect  supplies,  ammunition  and  POL  levels  for 
all  entities.  Communications  and  IEW  affects  on  communications 
are  also  modeled. 

CONSTRUCTION: 

Human  Participation:  Required  for  decisions  and  processes. 
Model  will  continue  to  run  without  decisions. 

Time  Processing:  Dynamic,  time  stepped  model.  Progresses 

through  processes  at  user  specified  ratio  of  exercise  time  to 
real  time. 
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Treatment  of  Randomness;  Land  and  air  attrition 
deterministically  based  on  Lanchester  Coefficients. 

Sidedness ;  Two-sided,  symmetric.  Red  side  has  less  complex 
logistics  play. 

LIMITATIONS :  Does  not  model  low  intensity  conflict  or  biological 

warfare.  Does  not  model  Naval  operations. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Seminar  mode,  interface 

to  ATCCS  and  linkage  to  other  models  (CCTT  and  CBS)  are  Pre-Planned 
Product  Improvements. 

INPUT :  Scenario  preparation  requires  input  of  Table  of 

Organization  and  Equipment  (TOE)  for  each  unit,  and  each  units 
starting  location  and  percentage  strength.  Unit  templates  and 
default  conditions  are  available.  Exercise  control  requires  input 
of  orders  through  use  of  alpha-numeric  terminal  menu  screens  and 
graphics  pointer  device  (mouse). 

OUTPUTS :  Output  of  reports  is  to  alpha-numeric  terminals  and 
printer,  maps  and  unit  positions  output  to  graphics  display  system. 

HARDWARE  AND  SOFTWARE: 

Computer  (OS):  Digital  Equipment  Corp.  (DEC)  MicroVAX  systems 
with  VMS  operating  system  (fielded  on  MicroVAX  II  and  3100;  1 0  MV 
IIs  or  5  MV  3100s  per  system). 

Storage :  Minimum  requirement  per  MicroVAX:  140  MB  disk  space, 

95  MB  tape  drive,  1 6  MB  RAM. 

Peripherals :  Each  of  ten  (10)  workstations  requires  the 

following:  1  graphics  controller,  1  laser  disk  player,  1  26" 

color  monitor,  3  terminals,  1  printer. 

Programming  language:  Modula  II. 

Documentation :  Operator's  and  User's  manuals  are  currently 

available.  Technical  and  software  documentation  will  be 
provided  when  the  objective  system  is  released. 

SECURITY  CLASSIFIED:  UNCLASSIFIED. 

GENERAL  DATA: 

Database :  Weapon  characteristics  database  and  terrain  databases 
are  static,  and  sufficient  for  most  scenarios.  Estimate  several 
man-months  effort  to  add  new  or  additional  weapon  systems,  two 
or  more  man-years  to  prepare  new  terrain  databases.  Scenario 
databases  are  dynamic.  ECG  should  be  capable  of  creating  a  new 
scenario  within  an  8  hour  period. 

CPU  Time  per  Cycle:  Varies  proportionally  with  size  of  exercise 
(number  of  units)  and  complexity  of  scenario.  No  statistical 
data  is  currently  available. 
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Data  Output  Analysis:  No  special  tools  currently  available. 
Sufficient  reporting  capabilities  available  to  conduct  a  thorough 
review  of  the  combat  situation,  but  analysis  must  be  done 
manually . 

Frequency  of  Use:  Normal  minimum  usage  will  be  semiannually  for 
active  and  once  per  year  for  reserve  components.  Actual  usage 
will  depend  on  local  command  policy. 

Users :  BBS  will  be  fielded  to  active/reserve  components 

independently  at  approximately  38  locations. 

Comments :  Interim  BBS  (IBBS)  has  been  fielded  to  several  sites 

with  positive  user  response.  Objective  system  will  run  on  CBS 
workstation  hardware. 

Releasabilitv :  Executable  code  releasable  to  all  US  Army 

activities,  and  other  approved  parties.  Source  code  released 
only  with  approval  of  Configuration  Control  Board. 
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TITLE:  Battlefield  Planning  System  (BPS) 
MODEL  TYPE:  Analysis 


DATE  IMPLEMENTED:  10/24/90 


PROPONENT:  TRADOC  Analysis  Cotrmand- White  Sands  (TRAC-WSMR) 

White  Sands,  M  88002-5502 

POINT  OF  CONTACT :  MAJ  Bruce  Robinson,  TRAC-WSMR 

PURPOSE:  A  decision  aid  to  assist  the  maneuver  brigade  and  division 
staffs  with  the  planning  process. 

DESCRIPTION :  An  automated  decision  aid  that  performs  terrain  analysis 

using  digital  terrain  data,  wargames  courses  of  action  through  combat 
modeling,  and  produces  operational  documents  such  as  orders  and  overlays 
to  support  the  selected  course  of  action. 

LIMTTATTCNS :  Availability  and  detail  of  digital  terrain  data. 
Availability  of  weapons  performance  data. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  None. 


HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS) :  Hewlett-Packard  9000/300  series  computer  with  UNIX 
operating  system. 

STORAGE:  15  Mb  disc  space,  4  Mb  RAM  ■•'•eguired.  Terrain  data  stored  on 
cartridge  tape. 

PERIPHERALS:  BW  or  color  printer,  mouse,  high  resolution  color  monitor, 
cartridge  tape  drive,  large  scale  mechanical  plotter. 

PROGRAMING  LANGUAGE:  Pascal  and  C. 

DOCUMENTATICN :  User's  manual  and  technical  documentation. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED. 

GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE:  Digital  terrain  data,  weapons  performance  data,  historical 
weather  data. 

CPU  TIME  PER  CYCLE:  Combat  model:  5  min  epu  time  =  60  min  battle  time. 
Terrain  analysis:  Varies  on  whats  being  done. 

DATA  OUTPUT  ANALYSIS:  Ccmbat  model:  Various  measure  of  effectiveness 
data  provided.  Terrain  analysis:  User  interprets  output. 

FREQUENCY  OF  USE:  Depends  on  user. 

USERS:  CISC,  TRAC-WSMR,  USMA,  ETL,  TEXOCM,  HQ  III  Corps,  1st  ID,  1st 
CD,  4th  ID,  2nd  AD,  3rd  ACR,  35th  ID,  Engr  School,  PM-OPTADS. 

CEMENTS :  Model  incorporated  into  Maneuver  Control  System  (MCS) . 
PiUfcAjnerto/  to  passed  off  to  PM-OPTADS  nit  May  91 . 
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TITLE :  Battlefield  Related  Analysis  of  Concepts  and  Hardware 

BREACH 

DATE  IMPLEMENTED:  1984. 

MODEL  TYPE:  Analysis  {BREACH  is  a  programming  language  used  to 
develop  small  unit  battlefield  engagement  simulations). 

PROPONENT :  U.S.  Army  ARDEC,  Advanced  Systems  Concepts  Office, 

Concepts  Analysis  Division,  Picatinny  Arsenal  NJ  07806-5000. 

PURPOSE :  BREACH  is  a  programming  language  used  primarily  in 

research  and  development  areas.  In  some  instances  it  is  used  in 
analyses  of  weapon  systems  to  evaluate  their  effectiveness  against 
various  targets  as  well  as  their  effectiveness  in  mixes  with  other 
systems.  Since  BREACH  is  a  programming  language,  tactics  could  be 
altered  with  coding  changes,  therefore  combat  development  issues 
which  involve  doctrine  guestions  can  overlap  and  integrate  with 
effectiveness  issues. 

DESCRIPTION: 

Domain :  BREACH  has  land,  air,  and  water  capabilities  in  its 

language  structure. 

Span :  Mainly  coded  for  studies  of  individual  systems  at  company 

level  and  below. 

Environment :  Square-based  grid  system  with  detailed  terrain  maps 
for  vegetation,  elevation,  mobility  and  obstacles.  BREACH 
features  the  capability  to  convert  each  square  grid  into  two 
triangles  to  represent  continuous  terrain.  Models  roads,  rivers, 
and  barriers.  BREACH  is  excellent  for  representing  buildings  and 
urban  warfare  modeling. 

Force  Composition:  Basically  recommend  starting  at  company  level 
or  below,  with  some  supporting  elements  (e.g  helicopters, 
artillery,  mortars,  etc.)  Plays  Blue  vs  Red  engagements. 

Scope  of  Conflict:  Conventional  type  weapons. 

Mission  Area:  All  conventional  missions. 

Level  of  Detail  of  Processing  and  Entities:  Individual  elements 
(tanks,  APCs,  helicopters,  soldiers,  etc).  Attrition  data  may 
be  input  as  a  single  Monte  Carlo  based  probability  of  kill  or 
taken  in  whatever  format  given.  Attrition  data  is  usually 
derived  from  other  performance  models.  BREACH  also  gives  the 
capability  to  "hook  in"  performance  models  as  subroutines. 
Movement  may  be  done  at  the  organization  level  or  individual  unit 
level  as  required  with  simple  BREACH  language  commands  (e.g.  PATH 
and  MOVE  commands).  Communications  must  be  explicitly  modeled  by 
the  programmer  if  needed. 
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CONSTRUCTION: 

Human  Participation:  A  capability  exists  to  develop  models  with 
user  interaction,  however  models  written  at  the  present  do  not 
require  human  interaction. 

Time  Processing:  Normally  dynamic,  event-sequenced. 

Treatment  of  Randomness:  Can  be  either  stochastic  or 

deterministic,  depending  on  model  written. 

Sidedness :  Can  be  either  one-  or  two-  sided  depending  on  the 

problem  to  be  modeled . 

LIMITATIONS :  Requires  user  to  program  engagements. 

PLANNED  IMPROVEMENTS /MODIFICATIONS :  Currently  runs  on  the  CDC  6600 
and  Cyber  825  computers  at  ARDEC.  PC-Version  forthcoming  in  1991. 

INPUTS :  Parameters  for  mines,  minefields,  rollers,  plo;,c, 

munitions,  sensors,  vehicles,  and  weapons  systems  must  be  input  for 
basic  data.  Also  need  movement  data  as  well  as  routes  of  advance 
for  groups  of  units.  Once  this  basic  data  is  provided  the  user 
then  develops  the  engagement  through  the  use  of  the  BREACH 
commands . 

A  newly  developed  BREACH  Preprocessor  downloads  data  files 
from  the  Combined  Arms  and  Support  Task  Force  Evaluation  Model 
(CASTFOREM).  Most  input  data  mentioned  above  will  be  gathered  from 
CASTFOREM  using  the  preprocessor  for  data  consistency  purposes. 
Scenario  development  for  BREACH  models  will  be  derived  as  subsets 
of  CASTFOREM  scenarios  and  aided  by  the  use  of  the  preprocessor. 

OUTPUT :  Standard  output  includes  event  tables,  vehicle  losses,  and 
plots  as  well  as  any  output  the  programmer  develops  with  the  use 
of  BREACH  output  commands . 

HARDWARE  AND  SOFTWARE: 

Computer :  Main  execution  on  the  CDC  6600  and  Cyber  825  using 

the  NOS/BE  operating  system. 

Storage :  Depends  on  model  written  however  typical  models  execute 
with  between  150000  and  240000  octal  core. 

Peripherals :  The  BREACH  Preprocessor  was  developed  to  execute 

on  a  Zenith  ZWX-248-62  PC. 

Programming  Language:  BREACH  is  written  in  FORTRAN.  The  Pre¬ 
processor  is  written  in  Turbo  PASCAL  and  DBASE  IV. 

Documentation :  BREACH  programmer,  analyst,  and  users'  manuals. 

Preprocessor  documentation  available  February  1991. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED  but  data  often  classified. 
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GENERAL  DATA: 

Data  Base:  One  month  from  scratch,  one  or  two  days  when 

downloaded  from  CASTFOREM  based  scenario. 

Engagement  Scenario  Development:  One  to  four  weeks  depending  on 
engagement  scenario  modeled  and  user's  experience. 

Learning  Time  to  Exercise  Previously  Written  Engagements:  One 
to  three  days . 

CPU  time  per  Replication:  Depends  on  engagement  scenario 

developed . 

Data  Output  Analysis:  Programmer  may  develop  output  analysis 

using  BREACH  commands. 

Freguency  of  use:  Two  to  three  engagement  simulations  typically 
developed  per  year. 

Users :  Advanced  Systems  Concepts  Office,  ARDEC  in  support  of 

PM-GMG,  Armament  Engineering  Directorate  (Precision  Munitions), 
Close  Combats  Armaments  Center  (Tank  Munitions). 

Comments ;  BREACH  is  an  alternative  to  the  development  of  larger 
operational  models  for  evaluating  new  technologies.  The  concept 
is  to  build  smaller  scale  battlefield  engagement  simulations 
derived  from  the  larger  models.  The  smaller  models  are  a  snapshot 
of  force-on  force  models  where  technology  improvements  will  have 
an  effect  on  the  outcome  of  tactical  operations.  The  smaller 
models  can  be  increased  in  detail  where  required  to  explore 
fighting  capability  improvement  with  a  new  concept.  It  is  a 
quicker,  simpler,  less  expensive  solution.  Payoffs  to  ARDEC: 
Adequate  consideration  in  decision  making  processes  for  new 
concepts,  particularly  at  the  TRADOC  force-on-force  level; 
Increased  understanding  of  the  way  new  technology  concepts  play  in 
battlefield  situations. 
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TITLE:  Battlegroup  Model  (BGM) 


Date  Implemented:  1983/84 


MODEL  TYPE:  Analysis 

PROPONENT:  Defence  Operational  Analysis  Establishment  (DOAE) 

POINT  OF  CONTACT:  T  R  Howard ,  DOAE 
PURPOSE: 

The  BGM  is  primarily  used  for  anti-armour  weapon  mix  comparisons,  to  assess 
the  relative  systems  effectiveness  against  targets  together  with  support 
systems . 

DESCRIPTION: 

Domain:  Land. 

Span:  Represents  combat  at  Battlegroup  vs  RED  Regiment  level.  Can  also  be 

used  at  Battlegroup  vs  RED  Company  level. 

Environment :  Statistical  representation  of  terrain.  Cultural  features  must 

be  taken  into  account  by  the  scenario  designer.  Represents  combat  by  day  or 
by  night  dependant  on  data  set. 

Force  Composition:  Force  composition  is  specified  in  terms  of  type  and  number 
of  weapons  in  each  weapon  group,  for  BLUE  and  RED. 

Scope  of  Conflict:  Direct  Fire  engagements  modelled  explicitly.  Limited 

representation  of  Indirect  Fire  and  Air  effects. 

Mission  Area:  Conventional. 

Level  of  Detail  of  Processes  and  Entities:  Number  of  individual  weapon 
systems  represented.  Infantry  represented  as  sections.  Weapons  are  grouped 
as  specified  in  data  base,  and  all  weapons  of  one  type  within  a  group  are 
treated  as  an  entity  for  attrition  calculations. 
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CONSTRUCTION 


Human  Participation:  None. 

Time  Processing:  Done  implicitly  within  scenario  "story-line". 

Treatment  of  Randomness:  Attrition  deterministically  based  on  Lanchester 

Coefficients . 

Sidedness :  Two-sided,  symmetric  model. 

LIMITATIONS:  Models  only  statistical  terrain.  No  account  taken  of  logistics. 

Perfect  C3  assumed. 

PLANNED  IMPROVEMENTS/MODIFICATIONS:  Graphical  interface  for  easier  scenario 
development  currently  being  added. 

INPUT:  Weapon  characteristics  and  SSKPs.  Scenario  "story  xine"  in  terms  of 

time/posi tion/ targets  for  engagement. 

OUTPUT:  Attrition  and  total  casualty  figures,  and  overall  outcome  of  battle. 
HARDWARE  AND  SOFTWARE 

Computer:  DEC  VAX  with  VMS  operating  system. 

Storage:  7400  blocks  (3.7  megabytes)  for  executable  code. 

Peripherals:  Minimum  requirements,  1  VT  terminal. 

Programming  Language:  FORTRAN  77,  DCL 

Documentation:  Extensively  documented,  with  published  user  guide  and  papers 

explaining  techniques  used. 

SECURITY  CLASSIFICATION:  Unclassified. 

GENERAL  DATA: 

Users:  DOAE  and  MINDEF  Singapore. 
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TITLE :  Battle  Group  War  Game 

MODEL  TYPE:  Analysis. 


DATE  IMPLEMENTED:  1958. 


PROPONENT :  BGWG  Section,  CA4  Division,  RARDE,  Ft  Halstead,  Kent, 

England,  U.K. 

POINT  OF  CONTACT:  I.  S.  Gardner,  CA4 ,  RARDE,  Ft  Halstead,  Kent, 
U.K.,  0959-32222,  ext  2444. 

PURPOSE :  The  game  is  a  research  and  evaluation  tool,  dealing 

primarily  with  weapon  systems  development  and  effectiveness.  It 
can  also  be  used  to  assess  force  capability  and  requirements, 
dealing  with  courses  of  action,  mix  and  effectiveness. 

DESCRIPTION: 

Domain :  Land . 

Span :  Local. 

Environment :  Digitized  terrain  consists  of  data  for  each  100 

meter  square.  Terrain  features  include  spot  heights,  3  types  of 
vegetation,  2  types  of  building,  rivers,  roads,  bridges  and 
obstacles.  The  model  can  handle  any  time  of  day  in  any  weather 
conditions . 

Force  Composition:  Up  to  regimental  level. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Any  conventional  missions  within  the  domain. 

Level  of  Detail  of  Processes  and  Entities:  The  lowest  entities 
modelled  are  fire  teams  and  individual  vehicles.  Attrition, 
movement  and  target  acquisition  are  modelled  for  each  entity. 

CONSTRUCTION: 

Human  Participation:  Required  for  decisions  and  processes. 

Time  Processing:  Processing  is  dynamic,  the  model  uses  time 

stepping . 

Treatment  of  Randomness:  The  model  is  stochastic,  it  uses  the 
Monte  Carlo  method. 

Sidedness :  The  model  is  two-sided  and  symmetric. 

LIMITATIONS :  Does  not  model  C3I  in  any  detail,  close  combat  and 

air/ground  interactions  are  not  modelled  adequately. 

PLANNED  IMPROVEMENTS /MODIFICATIONS :  None . 
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INPUT:  Terrain  data,  weather  data,  system  and  weapon 

characteristics  including  attrition  data,  mobility  data  and 
activity  timings. 

OUTPUT:  System  status  and  acquisitions  are  printed  during  the 

game.  Records  of  all  direct  fire  and  indirect  fire  events  and  mine 
encounters  are  recorded  manually. 

HARDWARE  AND  SOFTWARE: 

Computer :  Designed  to  run  on  a  VAX  computer  with  a  VMS  operating 
system. 

Storage :  64  megabytes. 

Peripherals :  The  minimum  requirement  is  1  printer  and  2  VT 

series  terminals. 

Programming  Language :  VAX  FORTRAN . 

Documentation :  There  is  a  set  of  4  manuals,  including  a  user's 

guide . 

SECURITY  CLASSIFICATION:  UNCLASSIFIED,  data  base  classified 

secret . 

GENERAL  DATA: 

Data  Base:  About  6  man-months  per  study. 

CPU  Time  per  Cycle:  About  20  minutes  of  processor  timer  per 

minute  of  game  time  (on  a  VAX-785). 

Data  Output  Analysis:  Manual. 

Freguencv  of  Use:  No  longer  in  regular  use. 

Users :  BGWG  section  CA4  Division  in  response  to  requests  for 

studies  by  a  series  sponsor  from  within  the  MOD. 

Comments :  This  game  was  originally  totally  manual,  but  became 

computer  aided  in  1980. 
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DATE  IMPLEMENTED:  10/30/90 


TITLE:  C3ISIM 
MODEL  TYPE:  Analysis 

PROPONENT:  Directorate  of  Ccmbat  Developments,  Concepts  &  Studies 
Division,  U.S.  Army  Air  Defense  Artillery  School,  Ft.  Bliss,  TX 

POINT  OF  CONTACT:  Fred  Lohrman,  USAADASCH,  ATTN:  ATSA-CDC-M,  Fort  Bliss, 
TX,  79916-0002 

PURPOSE:  C3ISIM  is  basically  a  many-cn-many  model  designed  to  simulate 
the  interaction  of  a  multitude  of  C2  nodes,  weapon  systems,  communications 
nodes,  and  intelligence  sensors  in  an  air  defense  and  SREM  defense 
scenarios.  It  models  both  Blue  and  Red  forces,  and  is  designed  to  be 
graphics-based,  user-oriented,  highly  versatile,  and  relatively  lew  cost. 

DESCRIPTION:  C3ISIM  is  an  effective  and  powerful  tool  for  supporting  the 
analysis  of  C3I  systems  and  employment  procedures.  The  arena  of  theater 
an  tactical  C3I  has  become  enormously  complex  in  recent  years.  With  that 
complexity  has  come  increasing  difficulty  in  analyzing  C3I  system 
effectiveness,  determining  system  impact  cn  ccmbat  operations,  and 
assessing  the  propriety  of  emerging  operational  concepts.  C3ISIM  helps 
botn  developers  and  potential  users  of  new  C3I  systems  to  quickly, 
accurately,  and  inexpensively  determine  how  well  the  design  or  specific 
employment  of  a  system  will  fulfill  operational  requirements,  by  modeling 
the  following  functioned,  areas: 

-  C2  processes  through  the  use  of  rule-based  decision  making 

-  Ccmbat  engagements  and  many-on-many  attrition  in  a  dynamic, 
user-con troled  environment  that  fully  exercises  the  C3I  architecture 

-  Technical  processes  such  as  target  detection,  electronic  warfare,  and 
communications  message  flow 

CONSTRUCTION:  The  C3ISIM  model  contains  a  number  of  processes  that  enable 
a  user  to  create  and  store  information  on  a  wide  variety  of  Blue  and  Red 
platforms.  The  types  of  platforms  that  can  be  represented  range  from 
major  C2  nodes  to  individual  weapon  platforms.  The  actions  that  each 
platform  can  perform  are  controlled  by  a  C2  ruleset.  A  ruleset  is  a  group 
of  software  subroutines  which  manage  the  resources  of  a  platform,  carry 
out  the  platform's  assigned  role,  and  maintain  its  relationship  with  other 
platforms.  Each  platform  is  assigned  its  own  ruleset.  The  model's 
ability  to  simulate  technical  processes  (such  as  radar  detection  and  radio 
transmission),  C2  processes  (C2  decision  making  and  direction),  and  combat 
engagement  processes  (air-to-air,  ground-to-air,  etc.)  in  a  single, 
dynamic  user  controlled  environment  places  it  at  the  forefront  of 
present-day  simulation  tools. 

LIMITATIONS :  Fidelity,  lack  of  available  databases 
PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  Chgoing  upgrading 
INPUT: 

-  Aircraft  flight  paths  and  profiles 

-  Scenario  data  (flight  path  timing  and  ground  deployments  for  both  Red  & 
Blue) 

-  Communication  networks 

OUTPUT:  High- resolution  video  simulation  of  the  scenario  participants  and 
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their  actions.  Each  runtime  process  creates  user  specified  data  files 
during  execution  of  a  simulation  in  the  farm  of  ASCII  and  binary  data 
files  that  can  be  manipulated  and  displayed  or  analyzed  off-line  at  a 
later  time. 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS) :  Silicon  Graphics  4D- series  workstation  with  UNIX  v3.x 
operating  system  with  Berkeley  4.3  enhancements . 

STORAGE:  Minimum  disk  storage  depends  upon  user,  but  760  Mb  are 
recommended. 

PERIPHERALS:  A  Personal  Computer  is  recommended  for  fur*  Ter  processing 
of  output  files;  Printer  with  serial  interface  to  print  scatisitcs  reports 

PROGRAMMING  LANGUAGE:  C-programming  language 

DOCUMENTATION:  Tactical  Missile  Defense  Extended  Air  Defense  Simulation 
(TMD/EAD  SIM)  model  Executive  Summary,  TMD/EAD  SIM  Methodology  Manual, 

TWD/  EAD  SIM  User's  Manual,  TMD/EAD  SIM  Programmer's  Manual. 

OTHER  COMMENTS:  Commercial  software  applications  sure  recommended  to 
further  manipulate  output  data;  32Mb  RAM  is  recommended  for  large 

SECURITY  CLASSIFICATION:  Model  is  UNCLASSIFIED,  however,  classification 
will  be  dependent  upon  the  classification  of  database  input  to  the  model. 

GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE:  Most  performance  &  parametric  data  is  available  in  standard 
U.S.  Government  databases  or  reference  documents;  C3ISIM  databases  are  TBD 

CPU  TIME  PER  CYCLE:  A  central  European  scenario  with  400  platforms  is 
about  1:1;  with  1 1 00  platforms  changes  to  about  1:10 

FREQUENCY  OF  USE:  Daily 

USERS:  USAADASCH,  USASDC,  USAMICCM,  USAASC,  USACACDA,  USATRAC,  MISIC, 

U.S.  Air  Force,  Teledyne  Brown  Engineering,  CAS,  DYNEHTCS 

COMMENTS:  Runtime  varies  greatly  depending  on  hardware  configuration, 
scope  of  scenario,  and  platform  activity;  it  increases  exponentially  as 
the  number  of  platforms  increases. 
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TITLE:  Campaign  Model  of  Air  Operations  (CAMAO) 


DATE  IMPLEMENTED:  1984 


PROPONENT:  LA2  Division,  DOAE 
POINT  OF  CONTACT:  Dr  R  J  Cherry,  DOAE 

PURPOSE:  CAMAO  is  used  primarily  for  theatre  level  assessments  of  new 

aircraft/munition  systems  and  the  vay  in  which  they  may  affect  campaign 
strategy.  It  has  also  been  used  to  provide  lover  level  model  with  an 
assessment  of  likely  levels  of  air  activity  throughout  the  campaign.  CAMAO 
could  be  used  to  give  military  staff  an  overall  view  of  tactics  in  an  air  war. 

DESCRIPTION: 

Domain:  Air;  limited  ground  interactions. 

Span:  120  airbases,  up  to  5  Corps  each  for  Blue  and  Red  ground  forces  in  each 

of  two  independent  sectors. 

Environment:  High  level,  aircraft  penetrate  in  corridors  and  hourly 

timesteps.  Certain  system  performances  can  be  varied  by  day  or  night. 

Force  Composition:  Mixed  raids  (Offensive  Counter  Air,  Escort,  Defence 

Suppression  and  Reconnaissance)  allowed. 

Scope  of  Conflict:  Primarily  used  at  2ATAF  level,  with  a  representative  slice 
of  UP  opposing  assets. 


Mission  Area: 
Nuclear. 

Most 

conventional 

missions 

with 

the 

exception  Chemical 

and 

Level  of  Detail 

of 

Processes  and 

Entities: 

In 

the 

air,  aircraft  types 

and 

numbers  -  note  aircraft  are  only  'flagged'  to  the  extent  of  knowing  their  home 
airbase.  Airbases  and  individual  HAS  and  terminal  defence  numbers.  For  the 
ground  forces  divisional  'boxes'  of  defined  size,  together  with  an  associated 
number  of  'average  radar  SAMs'  and  an  associated  number  of  'average  non-radar 
SAMs'.  Aircraft  operations  are  determined  by  'roling'  policy  -  each  aircraft 
type  may  have  a  given  percentage  in  each  of  its  possible  roles.  These  'roled' 
aircraft  may  then  be  apportioned  to  various  areas  of  the  battlefield  as 
defined  by  input  data. 
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CONSTRUCTION: 


Human  Participation:  Required  for  decision  making. 

Time  Processing:  Hourly  time  steps. 

Treatment  of  Randomness:  Fully  deterministic. 

Sidedness:  Two  sided.  Symmetric  in  Corps  areas  1-4,  Asymmetric  in  Corps  5, 
where  Blue  air  defence  airfields  in  that  Corps  are  constrained  to  operate 
within  Corps  boundaries. 


LIMITATIONS:  Does  not  model  the  effect  of  the  air  war  on  the  land  battle.  Of 
necessity  much  of  the  modelling  is  simplistic.  In  particular  air-to-air 
combat  has  caused  concern,  but  no  better  techniques  have  been  proposed.  No 
explicit  EW  other  than  an  allowance  for  self-screening  jamming.  No 
representation  of  munition  stocks  other  than  Cruise  (Ground  or  Air  launched) 
or  Ballistic  Missiles.  No  modelling  of  air-to-air  refuelling.  Fuel  stocks 
etc  assumed  sufficient. 


PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Being  adapted  to  allow  user-friendly 
input  of  campaign  decisions  using  graphics.  Graphics  display  of  campaign 
situation  for  Blue  and  Red  players,  also  an  umpire.  This  will  allow 
interactive  running  to  take  place.  Simplistic  representation  of  AEV  aircraft, 
stand-off  and  close-in  jammers.  Based  heavily  on  adoption  of  OCA  policy  by 
both  sides. 

INPUT:  Fixed  movement  of  ground  forces  and  associated  air  defences.  Airbase 
names,  defences,  shelters  and  aircraft  numbers.  Weapon  effectiveness. 
Detection  and  interception  probabilities.  Battle  damage  and  Random  fault 
factors.  Aircraft  allocations. 

OUTPUT:  Computer  Printouts. 
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HARDWARE  AND  SOFTWARE: 


Computer  (OS):  VAX  8650/VMS 

Storage:  Executable  code  requires  4100  blocks. 

Peripherals :  Minimum  -  1  input  terminal.  In  graphics  version  up  to  3  x 

(Sigmex  work  station  +  mouse  +  VT220). 

Programming  Language:  FORTRAN  77  (Run  macro  in  DCL) . 

Documentation:  High  and  low  level  available.  Low  level  essentially  a  line  by 

line  description.  All  documentation  held  on  tape  for  ease  of 
printout/use/modification. 

SECURITY  CLASSIFICATION:  Model  unclassified. 

GENERAL  DATA: 


Data  Base:  Preparation  time  depends  on  amount  of  low-level  support  available. 
Typically  18  man-months  for  an  acceptable  solution  -  would  take  many  many 
years  for  perfect  inputs. 

CPU  Time  Per  Cycle:  Dependent  on  database  size  and  player  interactions.  In 
automatic  run-through  typical  time  of  5  minutes  for  5  days  of  war. 

Data  Output  Analysis:  Limited  capability  to  draw  graphs  of  certain  Measures 
of  Effectiveness. 

Frequency  of  Use:  Varies  but  is  generally  in  use  by  one  team  or  another 

continuously. 

Users:  Various  study  teams  in  LA2  division. 

Comments :  Has  been  used  in  several  studies  in  the  past,  and  has  undergone 
several  phases  of  development  since  original  implementation  date.  Note  also 
existence  of  simpler  model  -  MINICAM  (MINI  CAMpaign  model)  -  only  two  aircraft 
types,  OCA  and  Offensive  Air  Support  (OAS).  Airbases  represented  in  groups. 
Attrition  due  to  all  sources  has  to  be  calculated  outside  the  model  and 
remains  constant  throughout  campaign  -  eg  "Aircraft  from  Group  1  attacking 
Group  9  will  suffer  10X  attrition  due  to  all  causes".  Has  been  used  for  doing 
range/payload  studies  for  stand-off  Missile  systems.  Because  of  its 
simplicity  data  can  usually  be  agreed  far  more  easily  with  customer  than  for 
CAMAO. 
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TITLE :  Canadian  Land  Forces  Training/Operational /Research  War  Game 
DATE  IMPLEMENTED:  1980's. 

MODEL  TYPE :  Training,  Operational  and  Research  using  manual  gaming 
with  computer  rules  off-line. 

PROPONENT:  Directorate  of  Land  Operational  Research  ( DLOR ) , 

Operational  Research  and  Analysis  Establishment  (ORAE),  National 
Defence  Headquarters,  101  Col  By  Drive,  Ottawa,  Ontario,  Canada, 
K1 A  0K2. 

POINT  OF  CONTACT:  Head,  War  Games  Section,  DLOR.  (address  above) 

PURPOSE :  The  set  of  rules  comprising  the  war  game  may  be  used  in 

any  of  the  above  mentioned  three  roles.  All  games  are  manual  with 
extensive  computer  support  to  assess  outcomes  of  actions.  The 
purpose  is  to  model,  with  detail  specific  to  the  particular 
requirement,  military  situations  which  arise.  As  a  research  tool 
it  deals  with  system  effectiveness.  As  a  training  tool  it  is  used 
both  in  team  training  and  as  an  exercise  driver  for  command  post 
exercises.  Each  game  may  be  played  without  computers  by  using 
manual  look  up  tables . 

DESCRIPTION :  May  be  structured  to  meet  sponsor  requirements. 

Domain :  Land,  Helo  &  F\W  Air  in  support  of  ground  forces. 

Span:  Regional. 

Environment :  Various,  played  on  manual  board. 

Composition :  Component  elements,  Blue  and  Red. 

Scope :  Conventional  -  special  rule  modules  developed  as 

required . 

Mission  Area:  High  and  Medium  intensity  battlefield. 

Level  of  Detail:  Various,  rule  dependant,  can  play  to  individual 
weapon  systems. 

CONSTRUCTION: 

Human  Participation:  Required  for  decisions  and  processes. 

Time  Processing:  Dynamic,  5  minute  game  time  steps. 

Randomness :  Stochastic,  Monte  Carlo. 

Sidedness :  Two-sided,  with  one  or  more  controllers. 
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LIMITATIONS :  Requires  experienced  military  gamers  and  computer 

operators  all  working  from  table  top  map  of  ground.  The  game  can 
handle  up  to  division  level  operations  but  is  more  suited  to 
brigade  and  battalion  operations. 

PLANNED  IMPROVEMENTS  &  MODIFICATIONS:  As  required  for  specific 

projects . 

INPUTS :  Weapons  effects,  orders  of  battle,  scenario  (from 

sponsor),  organizations,  tactics  and  orders. 

OUTPUT :  Various:  Usually  lists  of  current  strengths,  results  of 

combat  interactions,  location,  suppression,  status,  ammunition 
holdings,  etc. 

HARDWARE  &  SOFTWARE: 

Computer :  Now  converted  to  PC  DOS  machines. 

Storage :  20  MB  Hard  disk. 

Peripherals :  Printer. 

Programming  Language :  Various,  FORTRAN,  Basic  depending  on 

modules  used. 

Documentation :  DLOR  Staff  Note  89\16,  "Program  Description  of 

the  DLOR  Computer  Assisted  War  Game",  by  G.  Buffington. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED  without  data. 

GENERAL  DATA: 

Data  Base:  Various,  weeks  to  months  to  complete. 

CPU  Time  per  Cycle:  N/A. 

Data  Output  Analysis:  Almost  instantaneous  as  instructions  are 
input . 

Freguencv  of  Use:  3  to  5  times  per  year  until  1988,  now  not 
used . 

Users :  Training:  Staff  Schools  &  Colleges,  Brigades  -  Research: 
DLOR. 

Comments :  A  flexible  set  of  game  rules  which  can  be  tailored  to 
meet  sponsor  requirements. 
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TITLE :  Cannon  Row 


DATE  IMPLEMENTED:  1986. 


MODEL  TYPE:  Training  and  Education. 

PROPONENT :  Australian  Army  War  Game  Centre. 

POINT  OF  CONTACT:  Project  Leader  AWGC  62-2-9604411. 

PURPOSE: 

Analytical:  No. 

1 .  Research  &  Evaluation 

a.  Weapons  Systems 

Systems  Development? 

Systems  Effectiveness? 

b.  Force  Capability  and  Requirements 

Courses  of  Action  Assessment? 

Mix? 

Effectiveness? 

Resource  Planning 

c .  Combat  Development 

Current  or  New  Doctrine? 

Competing  Strategies? 

Policy  Study? 

2.  Operational  Support  Tool  (Decision  Aid) 

a.  Skills  Development 

Team?  yes 

Individual?  no 

b.  Exercise  Driver 

Field  Training  Exercise  Driver?  No 
Command  Post  Exercise  Driver?  Yes 

Individual  Exercise  Driver?  No 

DESCRIPTION: 

Domain:  Land. 

Span :  Local. 

Environment:  Day  or  night.  All  weather  conditions. 

Force  Composition:  Combined  forces,  limited  joint  forces. 
Blue  and  Red. 

Scope  of  Conflict:  Primarily  conventional  warfare  using 
conventional  weapons. 

Mission  Area:  Covers  all  conventional  missions. 

LEVEL  OF  DETAIL  OF  PROCESS  AND  ENTITIES: 

Entity :  Individual  weapon  to  brigade. 
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Process :  Attrition  of  weapons  and  personnel  based  on 

individual  kills.  The  probability  of  a  kill  is  based  on  weapon 
characteristics,  size  of  formations/units  and  postures. 

CONSTRUCTION: 

Human  Participation: 

(1)  Required: 

(a)  For  Decisions?  Yes 

(b)  For  Process?  Required  for  movements 

(c)  For  Both? 

(2)  Not  Required: 

(a)  Interruptable? 

(b)  Scheduled  Changes? 

(c)  Not  permitted? 

Time  Processing: 

( 1 )  Dynamic : 

(a)  Time  Step?  Yes.  All  events  occur  within  a 
game  discre1-0  game  turn. 

(b)  Event  Step?  No 

(c)  Closed  Form?  No 

(2)  Static: 


Treatment  of  Randomness : 

(1)  Stochastic: 

(a)  Direct  Computation?  Yes 

(b)  Monte  Carlo?  No 

(2)  Deterministic: 

(a)  Generate  a  value  as  a  function  of  an  expected 
value? 

(b)  Basically  Deterministic  (No  randomness)? 

Sidedness : 

(1)  One-sided? 

(2)  Two-sided: 

(a)  Symmetric? 

(b)  Asymmetric 

One  side  non-reactive? 

Both  sides  reactive?  Yes 

(3)  Greater  than  two-sided: 

(a)  Symmetric? 

(b)  Asymmetric 

One  or  more  side  non-reactive? 

All  sides  reactive? 


LIMITATIONS :  Land  warfare  only.  Climatic  conditions  based  on 

Australian  Environment  (requires  modifications  for  other 
locations).  Requires  modifications  for  additional  weapon  types. 


PLANNED  IMPROVEMENTS /MODIFICATIONS :  Attack  rules  are  being 
enhanced.  A  personnel/equipment  data  base  is  being  added  to 
provide  a  breakdown  of  casualties  by  type  and  injury  description. 
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INPUT:  Unit  posture  and  size,  Weapon  type,  ammunition  type, 

range . 

OUTPUT:  Results  are  displayed  but  may  be  optionally  printed. 

Results  may  be  stored  for  future  analysis. 

HARDWARE  AND  SOFTWARE: 

Computer  (OS):  IBM  PC  AT/XT  or  compatible  using  MS  DOS  3.2. 
Storage:  Limited  game  on  360k  disk.  Full  game  on  1.2Mb 

disk.  When  data  base  implemented  20Mb  disk. 

Peripherals :  Optional  Printer. 

Programming  Language:  Borland  Turbo  Pascal  Version  5. 
Documentation :  Manuals  available. 

SECURITY  CLASSIFICATION:  Restricted. 

GENERAL  DATA: 

Data  Base:  Not  applicable. 

CPU  Time  Per  Cycle:  Not  applicable. 

Data  Output  Analysis:  No  computerized  analysis. 

Freguencv  of  Uses:  More  than  20  times  per  year. 

Users:  All  units  and  training  establishments. 

Comments :  Reguires  minimal  set  up.  Board  is  required. 
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TITLE:  CCDECSIM  DATE  IMPLEMENTED:  Proposed  date 

for  first  version  -  July  1991. 

PROPONENT :  CA4  °ARDF . 

POINT  OF  CONTACT:  Mrs.  J.  Saunders,  (PO/BGWG  CA4 )  RARDE,  Fort 
Halstead . 

PURPOSE :  The  game/simulation  is  being  developed  to  provide  a 

facility  to  evaluate  and  compare  the  effectiveness  of  small  arms. 
It  will  be  able  to  run  either  as  a  Wargame  or  as  a  Simulation. 
CCDECSIM  is  still  under  development. 

DESCRIPTION :  CCDECSIM  is  a  model  that  deals  primarily  with  the 

Close  Combat  Battle  and  is  designed  to  assist  in  the  operational 
analysis  of  weapon  systems  within  company  level  scenarios.  It  is 
intended  to  run  either  as  a  simulation  or  as  a  closed  interactive 
game  where  two  players  may  control  the  opposing  forces.  It  is  an 
event  sequenced  stochastic  simulation  based  on  terrain  of  10m 
resolution  covering  an  area  of  up  to  5km  x  5km.  Men  and  vehicles 
will  be  represented  as  individual  units  who  are  able  to  move  and 
fire  independently  but  will  also  be  able  to  be  tasked  as  groups. 

A  maximum  of  100  units  per  side  can  be  presented. 

INPUT:  Weapon  characteristics  (lethality,  accuracy,  response 

time,  etc.),*  Movement  routes  and  speeds;  ORBATs;  Scenarios; 
Terrain  Characteristics;  Details  of  Equipment. 

OUTPUT :  DETAILED  LOG  OF  ALL  EVENTS. 

HARDWARE  AND  SOFTWARE:  2  VAX  station  3100  systems  (GPX  VAX 
station  compatible);  VWS  VAX  windowing  software;  PASCAL. 

USERS:  CA4  RARDE. 

ADDITIONAL  INFORMATION:  The  simulation/wargame  is  still  under 
development.  It  is  envisaged  that  the  first  version  will  be 
completed  June  1991.  Further  developments  will  then  be 
undertaken  as  required. 
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DATE  IMP!  .EMFTTTFID  •  01/01/88 


TITLE:  Chemical  Casualty  (CHEMCAS) 
mtdft,  type  :  Analysis 

PROPONENT:  U.S.  Army  Chemical  School,  Fort  McClellan,  AL  36205-5020 

POINT  OF  CCNTACT:  CPT  Kierzewski,  ATZN-CM-OC,  AV  865-4111/3307/3174 
U.S.  Army  Chemical  School,  Fort  McClellan,  AL  36205-5020 

PURPOSE:  CHEMCAS  is  an  analysis  model  used  to  evaluate  chemical  weapon 
systems  effectiveness  against  personnel  targets.  Primary  uses  in  the  past 
included  producing  weapons  effects  tables  for  EM  3-10-2  and  assessing  the 
expected  battlefield  hazard  from  enemy  chemical  attacks. 

DESCRIPTION:  CHEMCAS  is  a  stochastic,  cne- sided,  chemical  casualty  and 
hazard  area  assessment  model.  Using  individual  munition  footprints  from 
transport  and  diffusion  models,  CHEMCAS  overlays  these  footprints  an  a 
target  area  and  predicts  casualties  and  contamination  on  the  target.  For 
each  type  munition,  CHEMCAS  considers  errors  in  target  location,  Mean 
Point  of  Inpact  (MPI),  and  round- to- round  ballistic  dispersion.  CHEMCAS 
does  not  consider  terrain  explicitly  but  the  terrain  does  affect  the 
footprints  that  CHEMCAS  uses. 

CCNSTRUCTION :  Once  the  input  streams  are  specified  and  execution  start 
human  intervention  is  not  allowed.  The  model  is  dynamic  in  that  it 
portrays  the  effects  of  agent  for  user  specified  time  intervals  and 
considers  the  effects  from  rounds  that  arrive  on  the  target  at  differing 
times.  Using  bivariate  random  errors,  CHEMCAS  generates  random  impact 
points  then  overlays  the  munition  footprints  on  the  target  and 
accumulates  the  dosages  and  depositions.  CHEMCAS  is  one-sided  and 
can  consider  multiple  targets  and  fire  units  but  this  capability  has  not 
been  exercised  recently. 

LIMITATIONS :  Fireplanning  done  off-line.  Cne  route  of  entry  for  the 
chemical  agent. 

PLANNED  IMPROVEMENTS  AND  M3DIFICATICNS :  PC  version  with  integrated 
graphics  is  planned.  Also  integration  of  graphics  into  the  mainframe 
version. 


INPUT:  Weapon  parameters  such  as,  agent  fill  and  dissemination 
characteristics,  ballistic  errors,  and  aiming  procedures.  Environmental 
conditions  to  include  windspeed,  temperature,  and  stability.  Target  area 
size,  orientation. 

OUTPUT:  Computer  printouts  with  raw  data,  statistics,  and  analyzed  data. 
HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS):  UNYSIS  1100/70  OS  1100 

STORAGE:  1  Meg  memory  (to  run  either  main  program  or  NUSSE3  cloud 
generator),  3.8  Meg  disk. 

FERIPHERAT  :  Line  pxr inters 

PROGRAMMING  LANGUAGE:  ASCII  P0KIKAN 
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DCXJJMENTATICtJ :  Written  by  SAIC  Feb  88;  never  published. 

SECURITY  CLASSIFICATION :  UNCLASSIFIED 
GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE:  1  hr  for  normal  runs  (one  type  of  muni  tier) 

CPU  TIME  PER  CYCLE:  5  min 

DATA  OtfTPUT  ANALYSIS:  Upper  and  lower  confidence  levels,  expected 
values . 

FREQUENCY  OF  USE:  Quarterly. 

USERS:  USACMLS 

COMMENTS :  Currently  to  NUSSE3  transport  and  diffusion  model. 

Will  use  NUSSE4  when  that  model  becomes  available. 
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TITLE:  Combat  Analysis  Sustainability  Model  -  CASMO 

MODEL  CATEGORY :  Analysis  (Logistics). 


PROPONENT :  U.S.  Army  Concepts  Analysis  Agency,  Attn:  Force 

Systems  Directorate,  8120  Woodmont  Avenue,  Bethesda  MD 
2081 4-2797. 

POINT  OF  CONTACT:  Dong  S.  Kim,  AV  295-1652/(301)  295-1652 

PURPOSE :  CASMO  is  used  to  analyze  division  level  operations  of 
maintenance  and  logistics  support  in  peace  or  war  time.  It  is 
designed  to  serve  as  both  an  operations  support  and  a  capability 
assessment  of  major  weapon  systems  to  meet  mission  requirements. 

DESCRIPTION :  CASMO  is  a  stochastic,  event-step  simulation  model 

representing  the  operation  of  maintenance  and  logistic  support 
within  Army  Divisions.  CASMO  is  designed  to  assess  the 
capability  of  U.S.  Army  combat  units  and  their  supporting 
maintenance  and  logistics  organizations  to:  (1)  maintain  and 
repair  weapon  systems,  (2)  reorder  spare  parts,  and  (3)  perform 
other  maintenance  and  logistics  support  functions  under  a  variety 
of  operational  environments. 

Domain :  Land. 

Span :  Accommodates  any  division  in  a  theater  depending  on 

data  base. 

Environment :  Cartesian  Coordinate  based,  all  terrain.  Models 

shifts  in  day  and  night,  peace  and  war  time,  combat  postures. 

Force  Composition:  Any  type  of  division,  Blue  and  Red. 

Scope  of  Conflict:  Conventional  warfare,  conventional  weapons 
excluding  fixed  wing  aircraft  for  maintenance  repair. 

Mission  Area:  All  conventional  missions. 

Level  of  Detail  of  Processes  and  Entities:  Models  company 
level,  resolution  to  bumper  number  of  weapon  systems,  man-hours 
of  MOS,  service  equipment  and  spare  parts  by  NSN,  fuel  in 
gallons,  ammunition  in  rounds. 

CONSTRUCTION: 

Human  Participation:  Human  participation  is  not  required 
during  simulation.  Decisions  are  made  at  input. 

Time  Processing:  Dynamic,  Time  and  event  step  model.  Progress 
through  events  during  a  given  combat  cycle  time  period. 


46 


Treatment  of  Randomness:  Scheduled  and  unscheduled  maintenance 
requirements  are  randomly  selected  at  each  failure.  All  vehicles 
have  assigned  bumper  numbers  and  vehicles  are  assigned  for 
maintenance  by  random  selection  of  bumper  numbers.  Selection  of 
damaged  part  for  combat  maintenance  is  a  random  process.  CASMO 
uses  delay  distribution  for  several  types  of  time  delays.  Time 
delays  range  from  deterministic  delays  to  stochastic  delays  and 
include  most  of  the  traditional  probability  distributions.  These 
are  Deterministic,  Exponential,  Uniform,  Normal,  Log-normal, 
Gammer,  Weibull  and  Empirical  distributions. 

Sidedness:  Two-sided  but  operations  of  logistics  supports  for 

only  the  blue  side. 

LIMITATIONS :  Fixed  wing  aircraft  weapon  system  is  not  modeled. 

Attrition  of  maintenance  system  and  repair  personnel  are  not 
modeled.  Supply  trucks  are  not  modeled,  though  delay 
distributions  are  used. 

PLANNED  IMPROVEMENT/MODIFICATIONS :  Rotary  wing  weapon  system 
(Helicopters)  will  be  modeled. 

INPUT:  CASMO  requires  three  categories  of  input  data  to  complete 

sustainability  analysis.  These  are:  (1)  scenario  data  that 
include  weapons  and  ammunition  to  be  modeled,  combat  unit  and 
maintenance  unit  organization,  and  resources  of  maintenance  unit, 
(2)  unit  action  data  that  define  battery  or  company  maneuvers  and 
combat  action  during  the  simulated  engagements,  and  (3)  combat 
damage  data  that  determine  how  many  combat  "hits"  each  blue 
weapon  system  receives.  Combat  damage  data  is  combined  with 
shotline  data  derived  from  the  Sustainability  Prediction  for  Army 
Spare  Components  Requirements  for  Combat  (SPARC)  to  generate  a 
list  of  parts  damaged  for  repair. 

OUTPUT :  CASMO  produces  two  types  of  outputs  including  a  summary 

report  and  a  detailed  historical  event  file.  The  summary  report 
contains  two  categories  of  information,  namely,  queuing 
statistics  and  maintenance  resources  utilization  statistics.  The 
summary  report  is  designed  to  present  summary  information  useful 
to  three  types  of  users:  (1)  a  maintenance  decision  maker,  (2)  a 
supply  decision  maker  and  (3)  an  operational  decision  maker.  The 
summary  report  contains  MOS  utilization  per  shift,  maintenance 
throughput,  utilization  of  equipment /recovery  vehicle/contact 
vehicle,  deferred  maintenance  actions,  parts  status,  number  of 
back  orders,  fuel/ammunition  supply  data,  number  of  type  weapon 
systems  down,  and  availability  of  weapon  systems. 

HARDWARE  AND  SOFTWARE: 

Computer (OS) :  VAX  11/780,  VAX  8600  (VMS). 

Storage :  6  Mb. 

Programming  Language:  SIMSCRIPT,  FORTRAN. 
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Documentation :  Analyst  Guide,  User  Training  Manual. 

Adequately  documented. 

SECURITY  CLASSIFICATION:  Programs  are  UNCLASSIFIED,  input  data 
are  classified. 

GENERAL  DATA: 

Data  Base :  Data  base  must  be  developed  for  type  of  weapon 
systems  modeled.  Once  the  data  base  has  been  developed,  a  large 
portion  of  data  may  not  need  to  change  for  each  study  unless 
there  is  a  need  to  model  a  new  weapon  system. 

Time  Requirements:  24  weeks  (for  preparation,  run  and 
analysis ) . 

Frequency  of  Use:  Plans  2  studies  per  year. 

Users :  OTEA ,  CAA . 


48 


TITLE:  Combat  Identification  System  CCMD  Integrated  Air  Defense  (CISCIAD) 
Model 

MODEL  TYPE:  Analysis 

PROPONENT:  TRADOC  Analysis  Command  -  White  Sands  (TRAC-WSM*) 

White  Sands  Missile  Range,  ISM  88002-5502 

POINT  OF  CONTACT:  Mr.  Bill  Garrett,  USATRAC-WSMR,  ATRC-WBC,  White  Sands 
Missile  Range,  IM  88002-5502;  DSN  258-2307/3668 

PURPOSE:  CISCIAD  is  used  primarily  for  system  level  effectiveness  studies 
of  tactical  air  defense  systems.  It  is  also  appropriate  for  mission 
planning  analysis,  employment /deployment  analysis,  force  structure 
evaluations,  firing  doctrine  development,  battle  management  algorithm 
development  and  evolutionary  concept  evaluation. 

DESCRIPTION:  CISCIAD  simulates  large  scale  battles  between  air  defenders 
and  an  air  threat  in  a  conventional  environment.  It  is  usable  up  to 
Theater  level  and  typically  portrays  joint  forces.  The  model  represents 
the  functional  activities  of  the  defenders  and  the  threat  as  they  interact 
with  each  other  and  the  environment.  A  digitized  terrain  data  base  is 
used  to  depict  the  terrain  relief  as  well  as  cultural  features  of  the 
battlefield.  The  effects  of  environmental  factors  and  counter  measures 
are  simulated. 

The  level  of  detail  which  is  modeled  for  entities  and  processes  is 
typically  at  the  individual  system  level  and  sometimes  at  the  sub-system 
level.  The  entities  simulated  include  air  defense  missile  and  gun  systems 
interceptor  aircraft,  defense  suppression  and  penetrator  aircraft, 
helicopters,  early  warning  and  tracking  radars,  combat  identification 
systems,  command  and  control  element,  ccnmunicaticn  links,  tactical 
ballistic  missiles,  cruise  missiles,  jammer  and  escort  aircraft,  air 
bases,  airspace  weapons  control  volumes,  and  defended  assets. 

CONSTRUCTION:  CISCIAD  is  a  two-sided  symmetric  model  using  dynamic  event 
step  time  processing.  It  is  stochastic/ Monte  Carlo  and  neither  requires 
nor  permits  human  participation  or  interruption  during  execution. 

LIMITATIONS :  The  maximum  number  of  fire  units  and  aircraft  that  can  be 
played  are  300  and  1024  respectively.  Nuclear  &  chemical  warfare  &  total 
logistics  are  not  currently  modeled.  There  is  no  ground-to-ground  combat. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  When  time  permits,  a  graphical 
package  will  be  developed  to  assist  and  speed  scenarios  generation  and 
analysis  results.  Package  will  relate  to  analyst  workstation. 

INPUT:  Threat  and  friendly  aircraft  characteristics  and  vulnerabilities; 
SHORAD  system  characteristics;  HIMAD  system  characteristics;  Aircraft 
flight  paths  and  profiles;  Ccrrmand  and  Control  element  characteristics; 

ECM  jamming  data;  Combat  identification  system  data;  Visibility  data  for 
HIMAD  and  SHORAD  positions. 

OUTPUT:  Computer  printout  of  RED  and  BLUE  kills,  time  of  kills,  detection 
ranges,  engagement  ranges,  kill  ranges,  killer- victim  scoreboards, 
aircraft  identification  proficiency  of  movement,  etc.  Graphics  playback 
of  movement,  engagements,  and  kills. 


HARDWARE  AND  SOFTWARE: 


COMPUTER  (OS);  UNISYS  1192,  VAX  (VMS),  CRAY,  IBM,  HP  9000  (UNIX) 


STORAGE:  25K  -  150K  words  (scenario  dependent) 

PERIPHERALS:  Disk  storage  and  printer.  Color  Graphics:  RAMIEK 

PROGRAMING  LANGUAGE:  FORTRAN  77  (FORTRAN  8x  for  UNISYS) 

DOCUMENTATION:  VEDA  Report  Number  1 03292-86U/P1 035  Program 
Specification,  17  Feb  87;  VEDA  Report  Number  103066-87U/P1035  User's 
Manual,  6  May  87,  General  Research  Corp  CR-2-985  A  CCMD  Integrated  Air 

OTHER  COMMENTS:  DOCUMENTATION  CONTINUED:  Defense  Model  with  Command  and 
Control,  Apr  81 . 

SECURITY  CLASSIFICATION:  UNCLASSIFIED  code. 

GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE:  Scenario  dependent  but  usually  between  2  and  6  months. 

CPU  TIME  per  CYCLE:  Battle  hime/cpu  time  =  1  for  medium  sized  scenario 
on  HP  9000/600  (15  NHP  machine) . 

DATA  OUTPUT  ANALYSIS:  Post  processor  cpu  time  =  5  min  on  HP  9000/600 
FREQUENCY  OF  USE :  Continuous . 

USERS:  TRAC-WSMR,  CAA,  USAADASCH 

COMMENTS:  Government  agencies  can  obtain  CISCIAD  with  a  signed 
memorandum  of  agreement.  Government  Contractors  with  a  valid  contract 
requiring  the  use  of  CISCIAD  can  also  btain  the  model  with  the  approval 
of  the  TRAC  Commanding  General.  Inqu  res  for  obtaining  the  model  and 
supporting  data  bases  should  be  addressed  to  TRAC-TOD,  Ft.  Leavenworth,  KS 
66027-5200  or  calling  AV  552-551 1  or  commercial  91 3-684-551 1 . 
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TITLE :  Combat  Prescribed  Load  List  Model  -  Combat  PLL  Model 


DATE  IMPLEMENTED:  1984. 

MODEL  TYPE :  Analysis. 

PROPONENT :  U.S.  Army  Materiel  Systems  Analysis  Activity  (AMSAA), 

Inventory  Research  Office  (IRO),  800  U.S.  Custom  House,  2nd  and 
Chestnut  Streets,  Philadelphia,  PA  19106-2976. 

POINT  OF  CONTACT:  Marty  Cohen/Meyer  Kotkin,  DSN  444-3808/09  or 
(215)  597-8377. 

PURPOSE :  The  Combat  PLL  model  is  used  by  the  Army  Materiel 

Command  (AMC)  to  compute  Mandatory  Parts  Lists  (MPLs).  The  MPLs 
are  minimum  stockage  quantities  needed  to  support  an  organization 
in  a  specified  combat  environment.  The  model  is  an  analytic 
model  which  uses  the  theory  associated  with  S-1 ,  S  continuous 
review  inventory  systems  with  Poison  demands.  It  computes  the 
minimum  cost  stockage  needed  to  achieve  a  target  for  the  average 
number  of  equipment  operating  in  the  15  most  intense  days  of 
combat.  Stockage  for  each  end  item  is  computed  separately. 

Common  parts  need  to  be  rolled  up  by  the  user. 

DESCRIPTION: 

Domain:  Land  and  air. 

Span:  Computes  stockage  for  organizational  level  of  repair. 

Environment :  Controlled  by  wartime  usage  rates  which  are 

developed  outside  model. 

Force  Composition:  Blue  forces. 

Scope  of  Conflict:  Controlled  by  wartime  usage  rates. 

Mission  Area:  Provide  stockage  requirements  for  the  first  15 
days  of  combat. 

Level  of  Detail  of  Processes  and  Entities:  Calculates  PLL 
level  demands . 

CONSTRUCTION : 

Human  Participation:  Not  required  nor  permitted  while  model  is 
running . 

Time  Processing:  Dynamic,  time  and  event  stepped  model. 
Treatment  of  Randomness:  Basically  deterministic. 


Sidedness :  One-sided. 
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LIMITATIONS :  Cannibalization  is  a  not  played  in  the  model.  The 

Poison  demand  process  is  not  dependent  on  the  number  of  operating 
end  items.  Direct  support  supply  is  assumed  available  in  an 
Order  Ship  Time  (OST)  with  a  know  probability. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  To  be  determined  based 
on  need. 

INPUT :  Candidate  Item  File  (CIF)  which  identifies  the  parts  used 

on  a  given  end  item  along  with,  for  each  part,  mean  usage  between 
removal  of  the  part,  the  removal  task  distribution,  line 
replacement  unit  code,  and  unit  price.  End  item  identification 
and  densities.  Mission  profile  with  15-day  expected  usage  for 
the  end  item  for  various  measures  of  usage. 

OUTPUT :  Stockage  list  for  each  end  item  at  each  density. 

Expected  average  NMCS  during  15  days  of  intense  combat. 

HARDWARE  AND  SOFTWARE: 

Computer :  Runs  on  a  GOULD  computer  with  a  UNIX  operating 

system  but  can  be  easily  modified  for  other  computers. 

Storage:  Not  significant. 

Peripherals :  Minimum  requirement  is  1  VT100  terminal. 

Programming  Language :  FORTRAN . 

Documentation :  Documented. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED,  but  data  may  be 
classified. 

GENERAL  DATA: 

Data  base:  Varying,  depending  on  data. 

CPU  Time  per  Cycle:  Varying,  depending  on  applicability  of 
existing  data. 

Data  Output  Analysis:  Varying,  depending  on  desired  end 
product . 

Freguencv  of  Use:  Used  several  times  per  year  by  those  listed 
below. 

Users :  AMSAA,  AMC  Major  Subordinate  Commands  (MSCs),  and  MRSA. 

Comments :  Combat  Authorized  Stockage  List  (ASL)  Model  handles 

similar  data  at  direct  support  level  of  maintenance. 

Releasabilitv :  Releasable. 
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TITLE :  Combat  Sample  Generator  -  COSAGE  V 
DATE  IMPLEMENTED:  1980. 


MODEL  TYPE:  Analysis. 

PROPONENT :  U.S.  Army  Concepts  Analysis  Agency,  8120  Woodmont 

Avenue,  Bethesda,  MD  20814-2797. 

POINT  OF  CONTACT:  Mr.  John  Warren,  (AV)  295-1690/(301)  295-1690 

PURPOSE :  COSAGE  is  a  computerized  combat  assessment /weapons 

effectiveness  model  which  develops  information  on  ammunition 
expenditures  and  losses  of  personnel  and  equipment  during  a  24  to 
48-hour  period  of  combat.  The  principal  application  is  the 
forecasting  of  personnel,  ammunition,  and  equipment  requirements. 

DESCRIPTION: 

Domain:  Land  and  air. 

Span :  Division  area  of  operations. 

Environment :  When  terrain  parameters  are  required,  the  model 

randomly  selects  a  terrain  type  based  on  statistical  analysis  of 
the  region  of  interest.  These  parameters  are  then  used  to 
determine  line  of  sight,  movement  rates,  etc.  Night  and  day  are 
modeled,  and  visibility  varies  by  time  of  day. 

Force  Composition:  Combined  arms  army,  including  helicopters 
and  close  air  support. 

Scope  of  Conflict:  Conventional  warfare. 

Mission  Area:  Most  of  the  mission  areas  associated  with 
conventional  combined  arms  are  represented,  with  the  exceptions 
of  logistics  and  intelligence. 

Level  of  Detail  of  Processes  and  Entities:  Maneuver  unit 
resolution  is  typically  down  to  Blue  platoons  and  Red  companies. 
In  the  case  of  close  combat,  resolution  is  to  the  level  of 
individual  equipment  or  personnel  and  their  weapons,  with  each 
direct  fire  shot  modeled  explicitly. 

CONSTRUCTION : 

Human  Participation:  None. 

Time  Processing:  Dynamic  event  step. 

Treatment  of  Randomness:  Stochastic,  Monte  Carlo. 

Sidedness :  Two-sided,  symmetric. 
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LIMITATIONS :  Electronic,  biological,  chemical,  and  nuclear 

warfare  are  not  modeled,  nor  military  operations  in  built-up 
areas.  Logistics  and  intelligence  functions  are  not  represented. 

PLANNED  I MPROVEMENT S / MOD I F I CAT IONS:  No  major  improvements  are 
planned. 

INPUT :  Unit  organizations,  strength,  and  weapons;  orders  for 

each  maneuver  unit;  weapons  data  (single  shot  probability  of 
kill,  lethal  area);  sensor  capabilities;  terrain  parameters; 
movement  rates;  artillery  organization  and  characteristics. 

OUTPUT :  Killer-victim  scoreboard,  personnel  losses,  ammunition 

expenditures  by  shooter/ target  combination,  materiel  losses,  and 
unit  locations  on  plot  by  time. 

HARDWARE  AND  SOFTWARE: 

Computer  ( OS ) :  UNISYS  1100  series,  with  Exec  8.  Has  also  been 
installed  on  various  machines  with  UNIX  operating  systems. 

Storage :  420K  words  of  memory  for  model  and  data. 

Peripherals :  Line  printer.  CALCOMP  plotter,  if  plots  are 

desired . 

Programming  Language:  SIMSCRIPT  II. 5 
Documentation : 

•  Combat  Sample  Generator  User's  Manual,  DTIC  B070095L 

•  Combat  Sample  Generator  Program  Maintenance  Manual,  DTIC 
B073013L 

SECURITY  CLASSIFICATION;  UNCLASSIFIED. 

GENERAL  DATA: 

Data  Base:  6  man-months  required  to  acquire  data,  plus  3  man- 
months  required  to  structure  data  in  model  input  form. 

CPU  Time  Per  Cycle:  90  minutes  on  UNISYS  1100. 

Data  Output  Analysis:  1  month. 

Freguencv  of  Use:  Support  for  ten  to  fifteen  studies  a  year. 
User:  U.S.  Army  Concepts  Analysis  Agency. 

Comments :  COSAGE  is  linked  to  the  following  models:  FORCEM 

(Force  Evaluation  Model),  CEM  (Concepts  Evaluation  Model),  WARF 
(Wartime  Replacement  Factors),  and  WARS  (Wartime  Ammunition  Rates 
System) . 
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TITLE: 


COMBAT- SIM 


DATE  IMPLEMENTED:  1986. 


MODEL  TYPE:  Training  and  Education. 

PROPONENT :  Australian  Army  War  Game  Centre. 

POINT  OF  CONTACT:  Project  Leader  AWGC  62-2-9604411. 

PURPOSE : 

Analytical : 

1 .  Research  &  Evaluation 

a.  Weapons  Systems 

Systems  Development? 

Systems  Effectiveness? 

b.  Force  Capability  and  Requirements 

Courses  of  Action  Assessment? 

Mix? 

Effectiveness? 

Resource  Planning 

c .  Combat  Development 

Current  or  New  Doctrine? 

Competing  Strategies? 

Policy  Study? 

2.  Operation  Support  Tool  (Decision  Aid) 

a.  Skills  Development 

Team?  Yes 

Individual?  No 

b.  Exercise  Driver 

Field  Training  Exercise  Driver? 
Command  Post  Exercise  Driver? 
Individual  Exercise  Driver? 


No 

Yes 

No 


DESCRIPTION: 

Domain :  Land . 

Span :  Regional / local . 

Environment :  Day  or  night.  Full  range  of  weather. 

Terrain  (height,  slope,  vegetation). 

Force  Composition:  Joint  and  Combined  Forces.  Red  and  Blue. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  All  conventional  missions. 

Level  of  Detail  of  Process  and  Entities: 

Entity :  Section/squad  up  to  company. 
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Process :  Intervisibility,  movement  detection,  attrition, 

generation  of  casualties  (battle  and  non-battle),  ammunition  and 
fuel  usage. 

CONSTRUCTION: 

Human  Participation: 

(1)  Required: 

(a)  For  Decisions?  Yes.  (System  continues  to  run) 

(b)  For  Process?  No 

(c)  For  Both? 

(2)  Not  Required: 

(a)  Interruptable? 

(b)  Scheduled  Changes? 

(c)  Not  permitted? 

Time  Processing: 

( 1 )  Dynamic : 

(a)  Time  Step?  Real  time 

(b)  Event  Step?  No 

(c)  Closed  Form?  No 

(2)  Static: 


Treatment  of  Randomness: 

(1)  Stochastic: 

(a)  Direct  Computation?  Yes 

(b)  Monte  Carlo?  No 

(2)  Deterministic: 

(a)  Generate  a  value  as  a  function  of  an  expected 
value? 

(b)  Basically  Deterministic  (No  randomness)? 

Sidedness : 

( 1 )  One-sided? 

(2)  Two-sided: 

(a)  Symmetric? 

(b)  Asymmetric 

One  side  non-restrictive? 

Both  sides  reactive?  Yes 

(3)  Greater  than  two-sided: 

(a)  Symmetric? 

(b)  Asymmetric 

One  or  more  side  non-reactive? 

All  sides  reactive? 


LIMITATIONS :  Maximum  of  384  units.  Maximum  of  a  2  Battalion 

Brigade  scenario. 


PLANNED  IMPROVEMENTS /MODIFICATIONS :  Increase  the  number  of 
stations  to  allow  for  more  than  2  Battalion  Brigades.  Increase 
the  number  of  units  to  be  modelled. 
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INPUT:  Scenario,  unit  characteristics,  weapon  characteristics 

terrain  characteristics. 


OUTPUT ;  Report  printouts.  Video  map  with  graphics  overlay. 
HARDWARE  AND  SOFTWARE: 

Computer  (OS):  IBM  PC  AT  MS  DOS  3.2.  Ten  stations  networked 
Storage :  20MB  disk  per  station  (more  preferred) 

Peripherals :  Laser  video  disk,  graphics  overlay  device, 

printers,  joy  stick. 

Programming  Language :  MODULA  2 . 

Documentation :  Draft. 

SECURITY  CLASSIFICATION:  Restricted. 

GENERAL  DATA: 

Data  Base:  3  man  days. 

CPU  Time  per  Cycle:  Not  applicable. 

Data  Output  Analysis:  No . 

Freguencv  of  Uses:  12  times  per  year. 

Users :  Battalions/Brigades,  Advanced  Officer  Courses. 
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DATE  IMPLEMENTED:  01/01/90 


TITLE:  Combined  Anns  and  Task  Force  Evaluation  Model  (CASIPOREM) 

M3DEIL  TYPE :  Analysis 

PROPONENT:  TRADOC  Analysis  Center  -  White  Sands  Missle  Range  (TRAC-WSMR) , 
WSMR,  NM  88002 

POINT  OF  CONTACT:  Carrol  R.  Denney,  IRAC-WSMR,  Bldg  1401,  White  Sands 
Missile  Range,  NM  88002  AV  258-3029  Commercial  505-678-3029 

PURPOSE:  CASTFOREM  is  the  lowest  echelon,  highest  resolution,  systemic 
combat  simulation  model  in  the  family  of  Army  Model  Improvement  Program's 
(AMIP)  family  of  computer  simulation,  force-on- force  models .  Its  primary 
function  is  as  an  analysis  tool  used  to  select  between  carpeting  weapon 
systems  in  a  OQEA  process.  It  is  also  useful  to  examine  and/or  develop 
tactics,  and  for  parametric  analysis  on  various  weapon  system  performance 
parameters. 

DESCRIPTION:  CASTFOREM  is  a  stochastic,  event- sequenced,  opposing  forces 
simulation  of  ground  combat  involving  up  to  an  attacking  brigade  force  and 
against  a  defending  reinforced  regiment.  Although  not  artificially  con¬ 
strained  by  programming  considerations,  practical  limitations  of  computer 
run  time  and  complexity  of  analysis  would  dictate  that  the  above  force 
sizes  be  considered  maximum  and  that  battle  times  be  constrained  to 
firefights  of  ninety  minutes  or  less.  Ihe  model  is  used  in  a  fully 
automated  (batch)  mode  with  resolution  down  to  the  individual  weapon 
system  level.  Ihe  battle  is  fought  on  a  digitized  representation  of  the. 
terrain  which  may  vary  in  resolution.  Realistic  battle  conditions  are 
further  simulated  by  the  modeling  of  static  weather,  dynamic  obscurants 
(smoke  and  dust),  nuclear  and  chemical  contaminants,  implicit  electronic 
warfare,  explicit  communications  (message  passing,  delays,  and  networks ) , 
terrain  constrained  movements,  movement  in  formation,  detailed  search  and 
detection,  and  realistic  command  and  control  acheived  by  the  use  of 
decision  table  methodology.  Close  air  support,  helicopters,  air  defense, 
engineering  services,  fire  support,  close  combat,  and  combat  service 
support  are  modeled  in  sufficient  detail  to  support  the  combined  arms 
conflict. 

QCNSTRUCTICN: 

Human  Participation :  Not  required  —  Fully  automated  simulation. 

Time  Processing:  Dynamic,  Event  stepped. 

Treatment  of  Randomness:  Stochastic. 

Sideness:  TWo  sided  symmetric. 

LTMTTATICNS :  RAM  is  not  explicitly  represented  except  for  missiles. 
Weather  is  static  throughout  the  duration  of  the  game;  EW  is  generally 
implicit  except  for  jamming  red  radars. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  Improvements  and  modifications 
are  driven  by  study  requirements. 

INPUT:  Terrain  description  parameters;  Environment  parameters;  Weapons 
effects  data;  Weapon  system  descriptions;  Unit  orders;  Decision  tables; 
Organizational  structures;  CS  and  CSS  equipment  data;  Communications  data 
and  network  structures;  Tactical  Areas  descriptors ;  Sensor  data;  Maneuver 
network  structure;  Unit  description  data;  CXitput  directives. 

OUTPUT:  Each  event  specified  by  the  output  descriptors  is  recorded  for 
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postprocessing;  An  extensive  and  corprehens i ve  set  of  post  processing 
routines  is  availabe  with  the  model.  Graphical  playback  is  also  available. 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS) :  VAX  Series  running  VMS;  SUN  RISC  machines  running  UNIX; 

HP  900  series  running  UNIX;  Others. 

STORAGE:  Computer  main  memory  should  be  at  least  32  megabytes  on  the 
VAX  machines  and  64  megabytes  cn  the  UNIX  based  machines. 

PERIPHERALS:  Disk  storage  should  be  at  least  300  megabytes;  cartridge 
or  reel  tape; 

PROGRAMMING  LANGUAGE:  S INSCRIPT  II. 5  and  FORTRAN. 

DOCUMENTATION:  Available  in  six  volumes  and  annually  updated  are: 
Executive  Summary;  User's  Input  Guide;  Post- Processor's  Users  Guide; 
Methodologies  Manual;  Scenario  Writer's  Guide;  V&V  Manual. 

OTHER  COMMENTS:  Configuration  control  is  tightly  controlled  by  TRAC 
Model  Control  Policy.  User  Group  meets  periodically. 

SECURITY  CLASSIFICATION :  The  Model,  itself,  is  UNCLASSIFIED,  however, 
some  input  data  may  be  classified. 

GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE:  Setup  and  data  acquisition  times  vary  according  to 
scenario,  previous  model  usage  and  experience.  2  weeks  to  4  months. 

CPU  TIME  PER  CYCLE:  Variable.  Smallest  scenarios  run  at  5  minutes/rep 
while  largest  run  up  to  4  hours  per  rep;  Average  cpu/battle  =  1 .75/1 .00 

DATA  OUTPUT  ANALYSIS:  Variable.  Large  studies  normally  require  2  to  3 
months. 

FREQUENCY  OF  USE:  Daily  at  TRAC-WSMR,  Variable  at  other  installations. 

USERS:  TRAC,  Armor  School,  FISTC,  ARDEC,  SMQ,  MICCM,  DARPA,  and 
limited  Army  Contractors. 

COMMENTS:  Government  agencies  can  obtain  CASTFCREM  with  a  signed 
memorandum  of  agreement.  Government  Contractors  with  a  valid  contract 
requiring  the  use  of  CASTFCREM  can  also  obtain  the  model  with  the  approval 
of  the  TRAC  Commanding  General.  Inquiries  for  obtaining  the  model  and 
supporting  data  bases  should  be  addressed  to  TRAC-TOD,  Ft.  Leavenworth, 

KS,  66027-5200  or  call  AV  552-5511  or  ccmnercial  913-684-5511. 
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DATE  IMPLEMENTED:  10/26/90 


TITLE:  CXMO-T 
MODEL  TYPE :  Analysis 

PROPONENT:  Directorate  of  Combat  Developments,  Concepts  &  Studies 
Division,  U.S.  Army  Air  Defense  Artillery  School,  Ft.  Bliss,  TX 

POINT  OF  CONTACT:  Manuel  Amaro,  USAADASCH,  ATSA-CDC-M,  FT  BLISS,  TX 
79916-0002,  AV  978-2304/1238 

PURPOSE:  To  simulate  air  defense  weir  games  from  one-on-one  engagements 
to  theater  force  level. 

DESCRIPTION:  CCMD  III  is  a  computerized,  two-sided,  analytical  damage 
assessment /weapon  effectiveness  model.  CCMD-T  is  the  machine 
transportable  version  of  CCMD  III  and  runs  on  DEC  VAX  and  UNIVAC  computers 
a  framework  for  the  construction  of  system- level  simulations  of  tactical 
an  strategic  weapon  systems  in  a  modular  and  mutually  compatible  form. 

The  COM3  frame,  when  assembled  with  FORTRAN  weapon  decks  which  describe 
the  interacting  systems,  form  a  critical  event-stepped  Monte  Carlo 
simulation.  It  is  flexible  as  to  game  size  and  input/output  format  and  is 
extra  efficient  in  memory  use. 

CONSTRUCTION:  Simulation  consists  of  a  FRAME,  a  combination  of  WEAPON 
decks  (Red  and  Blue),  and  a  user  supplied  scenario  (Timing,  A/C  Tracks, 
RVIS) . 

LIMITATIONS :  May  be  long  turnaround  time  dependant  upon  machine/scenario 
Model  is  manpower  intensive  in  setup  time  and  output  data  reduction; 

Run  time  increases  nonlinearly  with  number  of  aircraft  in  scenario. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Dynamic  line  of  sight  (DLOS)  is 
in  the  process  of  being  implemented. 


INPUT: 

-  Threat  aircraft  characteristics  and  vulnerabilities 

-  ADA  system  characteristics  (weapons  decks) 

-  Aircraft  flight  paths  and  profiles 

-  Scenario  data  (flight  path  timing  and  ground  deployments) 

-  Threat  munition  characteristics 

-  ECM  jamming  levels 

OUTPUT: 

-  Computer  printout  with  input  data,  kill  summary,  and  specialized 
statistics  on  a  per-site/per-aircraft  basis 

-  Data  tape  for  extensive  post-processing  at  a  later  time 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS) :  MicroVAX  3500  with  VMS  Operating  System 

STORAGE :  2-RA70  280  Mb  disk  drives 

2-ADS  1 . 2  Gb  disk  drives 

PERIPHERALS:  1-TU81  1/2"  MAG  Tape  Drive;  1-TK50-70  Tape  Cartridge 
Drive:  1-Decwriter  III  System  console;  1-C.  ITCH  400  1pm  printer;  7-user  t 

PROGRAMMING  LANGUAGE:  FORTRAN 
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DOCUMENTATION:  Programmers  Reference  Guide  and  Users  Manual  far  each  of 
the  weapon  decks  and  the  GCMO  Input  language  (GOMEL) 

OTHER  COMMENTS:  None 

SECURITY  CLASSIFICATION :  UNCLASSIFIED 

GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE:  2-3  days  far  RVIS;  2-5  hrs  for  DLOS 

CPU  TIME  PEN  CYCLE:  1-5  minutes  for  small  scaiar ios 

DATA  OUTPUT  ANALYSIS:  Dependent  on  study 

FREQUENCY  OF  USE:  3-4  major  &  6-8  minor  studies/year 

USERS:  USAADASCH 
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TITLE :  Concepts  Evaluation  Model  -  CEM 

DATE  IMPLEMENTED:  1974. 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.S.  Army  Concepts  Analysis  Agency,  8120  Woodmont 

Avenue,  Bethesda,  MD  20814-2797 

POINT  OF  CONTACT:  William  T.  Allison,  (AV)  295-5236 

PURPOSE :  CEM  is  used  primarily  to  analyze  force  effectiveness  at 

theater  level  warfare.  It  is  designed  to  provide  a  tool  to 
assess  the  effectiveness  of  different  mixes  of  forces  and 
resources  and  to  estimate  ammunition,  equipment,  and  personnel 
requirements . 

DESCRIPTION: 

Domain :  Land  and  Air. 

Span :  Accommodates  any  theater  given  a  data  base;  has  been 

used  for  Korea,  Southwest  Asia,  and  Central  Europe. 

Environment :  Terrain  consists  of  three  types  representing  good 

cross  country  maneuverability,  marginal  cross  country 
maneuverability  and  road  bound.  Natural  and  man-made  barriers 
are  also  represented.  Terrain  is  described  in  rectangular  bands. 
Each  1 2-hour  division  level  cycle  represents  average  proportion 
of  day  and  night.  No  weather. 

Force  Composition:  Combined  forces  for  Blue  and  Red. 

Scope  of  Conflict:  Conventional  warfare. 

Mission  Area:  All  conventional  missions  except  unconventional 
warfare . 

Level  of  Detail  of  Process  and  Entities:  Simulates  command 
decisions  at  four  levels  from  theater  to  division.  Force  inputs 
as  Blue  brigade  and  Red  division.  Combat  occurs  between  Red 
divisions  and  Blue  brigades  along  a  continuous  FEBA. 

Accommodates  up  to  70  Blue  and  125  Red  divisions  with  up  to  51 
types  of  weapons.  Aircraft  are  aggregated  into  two  types;  Air 
Defense  Fighters  and  Tactical  Fighters.  The  latter  are  given 
daily  missions  of  Counter  Air  (CA),  Armed  Recon/Interdiction 
(AR/l),  or  Close  Air  Support  (CAS).  Attrition  to  CA  and  AR/l  are 
probability  of  kill.  Attrition  to  CAS  and  divisional  personnel 
and  equipment  is  derived  from  results  of  a  high  resolution 
simulation  used  to  extrapolate  for  the  actual  weapons  in  the  CEM 
engagements.  Logistics  are  highly  aggregated.  Movement  of  FEBA 
is  a  function  of  attacker  and  defender  final  to  initial  combat 
worth  ratios. 
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CONSTRUCTION: 

Human  Participation:  None.  Fully  automated. 

Treatment  of  Randomness:  A  deterministic  expected  value  combat 
simulation. 

Time  Processing:  Time  step  based  on  a  12-hour  division  level 
cycle . 

Sidedness :  Two-sided,  symmetric  model. 

LIMITATIONS :  Does  not  model  breakthrough,  airborne  assaults, 

engineer  functions,  transportation,  lines  of  communication, 
electronic,  chemical,  or  nuclear  warfare. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Different  combat 
attrition  samples  for  night  and  day;  deep  fires  against  second 
echelon  and  arriving  forces;  combat  attrition  of  GS  artillery. 

INPUT:  Terrain  map;  troop  lists;  TOEs  (personnel,  ammo,  POL, 

other  supplies,  tanks,  APCs,  helicopters,  anti-tank  missiles,  and 
artillery);  shooter- target  results  from  high  resolution 
simulation;  resupply  and  replacement  rates  (personnel,  ammo,  POL, 
other  supplies,  and  weapons);  arrival  schedule  for  resupply, 
reinforcing  artillery  battalions,  and  maneuver  units;  and  FEBA 
movement  tables . 

OUTPUT :  Computer  reports  stating  (periodic)  FEBA  locations, 

posture  profiles,  state  of  opposing  forces,  resources  expended, 
KIA,  WIA ,  CMIA,  and  DNBI;  and  weapons  hit,  destroyed,  damaged, 
abandoned,  and  repaired.  Graphic  (plotter  or  color  CRT)  display 
of  same  results. 

HARDWARE  AND  SOFTWARE: 

Computer:  UNISYS  1100/84;  CRAY  XM-P/48;  CRAY  II. 

Storage:  1.2  million  decimal  words. 

Peripherals :  Two  tape  drives  or  disks;  one  printer. 

Programming  Language :  ASCII  FORTRAN. 

Documentation :  CAA-D-85-1 ,  Volume  I,  Technical  Description, 

January  1985  (Revised  October  1987);  CAA-D-85-1,  Volume  II, 

Users'  Handbook,  August  1985.  (Revised  January  1990). 

SECURITY  CLASSIFICATION:  UNCLASSIFIED. 

GENERAL  DATA: 

Data  Base:  Acquisition  -  2  months;  Preparation  -  18 
man-months . 

CPU  time  per  Cycle:  UNISYS  1100/84  -  36  hours  (for  180  days 
simulation);  CRAY  XM-P/48  -4  hours  (for  180  days  simulation). 
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Data  Output  Analysis:  2  months. 

Frequency  of  Use:  800  times  per  year. 

Users :  U.S.  Army  Concepts  Analysis  Agency. 

Comments :  CEM  is  dependent  on  results  from  a  higher-resolution 

division  model  (presently  COSAGE)  for  combat  attrition  and 
munition  expenditures. 


64 


TITLE ;  Contingency  Force  Analysis  Wargame  -  CFAW 
DATE  IMPLEMENTED:  N/A. 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.S.  Army  Concepts  Analysis  Agency,  Attn:  (CSCA-SPC) 

8120  Woodmont  Avenue,  Bethesda,  MD  20814-2797 

POINT  OF  CONTACT:  Mr.  Robert  Hart,  (301)  295-1 574/ (AV)  295-1574. 

PURPOSE :  CFAW  is  used  primarily  to  examine  both  operation  plans 

and  contingency  plans  and  to  analyze  potential  conflict. 

DESCRIPTION: 

Domain:  Land,  Air,  and  over-the-shore  naval  operations. 

Span :  Scale  depends  on  specific  study  needs.  Reasonable  span 

ranges  from  division  to  small  theater. 

Environment :  Hex-based.  Each  hex  edge  incorporates  1  of  1 0 

possible  types  of  road  and  off-road  traf f icability  factors.  Each 
hex  is  one  of  seven  terrain  types,  which  include  mountains, 
hills,  null,  flat,  swamp,  urban,  and  water.  Hex  size  is  an  input 
parameter;  the  current  model  can  employ  four  49x49-hex  maps. 
Weather,  time  of  day,  and  day  and  night  are  modeled. 

Force  Composition:  Combined  and  joint  forces  can  be  modeled. 

Scope  of  Conflict:  Conventional  conflict  with  rear  area  and 
noncontiguous  FLOT.  Nuclear  and  chemical  play  is  limited  to 
initial  effects  (no  effects  of  contamination,  persistence, 
collateral  damage,  etc.). 

Mission  Area:  Air  (DCA,  CAS,  BAI ) ,  direct  and  indirect  fire 
(including  TBM  and  rockets),  air  defense,  airlift  (including 
airborne  and  airmobile),  and  barrier  operations  are  represented. 

Level  of  Detail  of  Processes  and  Entities:  Land  combat  units 
can  be  modeled  from  company  to  division  as  discrete  entities  with 
briyade/regiment  being  the  preferred  entity  size.  Units  are 
collections  of  direct  and  indirect  fire  weapon  types,  each  having 
a  descriptive  data  base  of  acquisition  and  kill  probabilities, 
fire  distribution,  and  other  input  parameters.  Attrition  on 
units  in  direct  fire  combat  is  adjudicated  by  a  differential 
equation.  Equation  parameters  are  obtained  from  a  detailed, 

Monte  Carlo  simulation  model.  Attrition  varies  with  posture  and 
terrain.  Combat  is  initiated  by  attack  by  an  aggressor  unit  and 
terminated  upon  player  command  or  by  breaching  a  player  specified 
attrition  threshold.  Model  is  a  single-echelon  command  and 
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control;  players  must  give  orders  to  each  unit  played  for 
movement.  Air  units  are  modeled  as  squadrons  of  individual 
aircraft  that  can  be  given  ground  attack,  defensive  counter-air, 
or  escort  missions. 

CONSTRUCTION ; 

Human  Participation:  Required  for  all  unit  mission  and 
movement  decisions. 

Time  Processing:  Dynamic,  Time-step.  Game  time  to  real  time 
is  variable. 

Treatment  of  Randomness;  Stochastic,  Monte  Carlo. 

Sidedness :  Two-sided,  symmetric. 

LIMITATIONS :  Non-reproducible  results  due  to  stochastic 

randomness  and  player  variabilities.  Altitude  is  not  played, 
which  degrades  air  defense  fidelity.  Player  span  of  control 
limits  practical  number  of  entities  per  side  to  approximately 
100.  Player  decision  variability  does  not  permit  replication  of 
a  specific  game.  Small  unit  combat,  to  include  SOF-type 
activities,  is  not  modeled. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Enhanced  logistics 
effects  and  improved  ability  to  divert  air  missions  to  immediate 
targets . 

INPUT:  Units:  weapon  counts,  ground  speed,  supply  consumption 

rates,  indirect  fire  damage  capability  and  range,  unit  size,  and 
designation.  Scenario:  terrain  description.  Attrition: 
individual  weapons  data,  terrain  effects  on  weapon  densities, 
probabilities  of  detection  and  kill  for  each  weapon  target 
pairing,  expected  aircraft  specific  exchange  ratios,  and  air 
defense  effectiveness.  Game:  initial  map  position  and  arrival 
time  for  each  unit  played. 

OUTPUT :  Current  status  (strength,  position,  and  activity)  and 

map  picture  of  playing  screen  as  desired  during  game.  Strengths 
over  time  of  weapons  by  location,  activity,  type,  etc.,  as 
desired  by  analyst  in  tables  and  charts. 

HARDWARE  AND  SOFTWARE: 

Computer:  VAX  780  with  VMS. 

Storage:  100  words. 

Peripherals :  Five  DEC  VT102  terminals,  three  Ramtek  RGB 

monitors  with  driver,  one  printer. 

Language :  FORTRAN . 

Documentation :  Under  development. 

SECURITY  CLASSIFICATION:  Unclassified,  but  data  bases  are  often 
classified . 


66 


GENERAL  DATA: 

Data  Base:  One  to  three  weeks  (given  information 
availability ) . 

CP(J  time  per  Cycle:  Approximately  20  mins  of  each  gaming  hour. 

Data  Output  Analysis:  Postprocessor /analytical  aids,  hard 
copy,  order  streams. 

Frequency  of  Use:  Six  to  eight  different  war  game  scenarios 
per  year. 

Users :  USACAA  operates  war  game  for  DA  Staff,  Army  agencies 

and  major  commands. 

Comments :  USACAA  performs  configuration  control,  model 

improvements,  and  maintenance. 
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DATE  IMPLEMENTED:  01/01/82 


TITLE:  Corps  Ammunition  Model  Expanded  (CAM-X) 

MODEL  TYPE :  Analysis 

PROPONENT:  IRADOC  Analysis  Command,  Ft  Lee  (TRAC-LEE),  VA 

POINT  OF  CONTACT:  Bruce  E.  Lasswell,  AV  687-1050,  Ft  Lee,  VA  23801 

PURPOSE:  To  furnish  information  on  how  supply  requests  may  be  satisfied 
under  constraints  of  load/unload  capability,  transportation  network,  and 
enemy  attack. 

DESCRIPTION:  CAM-X  is  a  physical  distribution  model  created  using  the 
MAWLOGS  Modeling  System.  It  can  be  run  either  stochastically  or 
deterministically.  The  size  and  complexity  of  the  system  and  transportion 
network  to  be  modeled  are  determined  by  the  analyst.  Requirements  for 
ammunition  are  input  to  the  model  based  on  other  model  outputs  or  by 
scenarios.  Generic  convoys  move  over  the  network  to  customers.  Supply 
points  and  hail  ted  vehicles  may  be  attacked.  All  phases  of  transportation 
are  considered . 

CONSTRUCTION: 

Human  Participation:  Not  required — scheduled  changes. 

Time  Processing:  Dynamic,  event-step. 

Treatment  of  Randomness:  Either  stochastic,  Monte  Carlo  or  basically 
deterministic  as  required  by  the  user. 

Sidedness:  One-sided. 

LIMITATIONS :  Model  requires  extensive  data  input  and  is  not  directly 
related  to  combat  models. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  None. 

INPUT:  Transportation  network,  ammunition  demands  (from  other  model 
outputs  or  SCORES  scenario),  destruction  probabilities,  rebuild  times,  and 
unit  locations  and  movement. 

OUTPUT:  Ammunition  delivered,  ammunition  destroyed,  transportation 
mode  utilization  and  schedules. 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS):  VAX  11/780. 

STORAGE :  Variable . 

PERIPHERALS:  Printer  and  tape  drive. 

PROGRAMMING  LANGUAGE:  FORTRAN  77. 

DOCUMENTATICN :  A  Users  Guide  for  LOGATAK,  A  Simulation  Model  to  Analyze 
Logistic  Network  Distributions  and  Interdiction.  1977,  (DLSIE  LD 
42543-MB) . 

CITHER  COMMENTS:  CAM-X  was  created  using  the  Models  of  the  Army 
Worldwide  Logistics  System  (MAWLOGS). 

SECURITY  CLASSIFICATION:  UNCLASSIFIED. 
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GENERAL  DATA  AND  TIME  REQUIREMENTS: 
DATABASE:  N/A. 


CPU  TIME  PER  cycle :  Varies. 

DATA  OUTPUT  ANALYSIS:  Two  weeks. 

FREQUENCY  OF  USE :  Cyclical . 

USERS:  U.S.  Army  Ordnance  Missile  and  Munitions  School. 

OOMENTS:  Government  agencies  can  obtain  CAM-X  with  a  signed 
memorandum  of  agreement.  Government  Contractors  with  a  valid  contract 
requiring  the  use  of  CAM-X  can  also  obtain  the  model  with  the  approval  of 
the  TRAC  Commanding  General.  Inquiries  for  obtaining  the  model  and  the 
supporting  data  bases  should  be  addressed  to  TRAC-TOD,  Ft.  Leavenworth,  KS 
65027-5200  or  calling  AV  552-5511  or  commercial  913-684-5511. 
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TITLE:  Corps  Battle  Analyzer  (OORBAN) 
MODEL  TYPE :  Analysis 


DATE  IMPLEMENTED:  05/01/90 


PROPONENT:  TRADOC  Analysis  Command  (TRAC),  Operations  Analysis  Center 
(QAC)  Fort  Leavenworth,  Kansas  66027-5200 

POINT  OF  CONTACT:  Mrs.  Homer,  ATRC-FM,  AV:  552-4595,  TRAC-OAC 
Fort  Leavenworth,  KS  66027-5200 

PURPOSE:  Scenario  development,  operational  concepts  ,  seminar  trainer 

DESCRIPTION :  OORBAN  simulates  battle  at  the  operational  level  between  a 
Blue  Corps  and  a  Red  Army.  While  the  primary  focus  is  on  the  ground 
battle,  the  model  also  plays  close  air  support,  battlefield  air 
interdiction,  helicopter  operations,  artillery,  and  air  defense.  The 
model  is  an  aggregated  representation  of  each  functional  area. 

CONSTRUCTION:  The  model  is  closed,  once  loaded,  it  requires  no  human 
participation  to  run.  It  is  a  dynamic  architecture  which  is  time  stepped. 
It  can  be  run  in  either  a  deterministic  or  stochastic  form.  The  model 
plays  forces  on  two  sides. 

LIMITATIONS :  Aggregated  output  data 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  None 

INPUT: 

-  Force  structure 

-  Systems  data 

-  Terrain 

-  Operational  orders  (templates) 


OUTPUT: 

-  Command  and  control  trace 

-  FEBA  plot 

-  Variety  of  assessment  data 
HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS):  VMS 
STORAGE:  50K 
PERIPHERALS:  Plotter 
PROGRAMMING  LANGUAGE:  FORTRAN 

DOCLMENTATICN :  Deep  Atk  Prog  Off  Final  Rpt,  30  Jun  85;  Tech  Overview, 

Mar  87;  CORBAN  Vol  I  -  Users  Manual,  Apr  86;  OORBAN  Vol  II-Data  Struc,  Apr 
86  OORBAN  Vol  III  -  Software  Arch,  Apr  86;  CORBAN  Vol  IV-Ops  Guide,  Apr  86 

SECURITY  CLASSIFICATTCN :  UNCLASSIFIED 

GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE :  2  Weeks 
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CPU  TIME  PER  CYCIE:  6  Hours  CPU/60  Hours  simulated  battle 


FREQUENCY  CF  USE:  Monthly  at  TRAC 

USERS:  Studies,  Study  Agencies,  and  Study  applications  for  which 

model  has  been  used:  Deep  Fires,  and  O/O  study,  DA;  Deep  Atk  Prog  Off  DAPO 

OOMENTS:  Government  agencies  can  obtain  OCRBAN  with  a  signed 
memorandum  of  agreement.  Government  Contractors  with  a  valid  contract 
requiring  the  use  of  VIC  can  also  obtain  the  model  with  the  approval  of 
the  TRAC  Commanding  General.  Inquiries  for  obtaining  the  model  and 
supporting  data  bases  should  be  addresses  to  TRAC-TOD,  Ft.  Leavenworth,  KS 
66027-5200  or  calling  at  AV  552-5511  or  ccmnercial  913-684-5511. 
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TITLE :  Corps  Battle  Simulation  -  CBS  (version  1.3) 

DATE  IMPLEMENTED:  1990. 

MODEL  TYPE :  Training  and  Education. 

PROPONENT :  Department  of  the  Army,  Project  Manager  for  Training 

Devices  (PM  TRADE),  12350  Research  Parkway,  Orlando,  FL 
32826-3276. 

POINT  OF  CONTACT:  Mr.  P.  Spangler,  DSN  960-4309/(407)  380-4309. 

PURPOSE :  CBS  is  used  primarily  to  train  Corps  and  Division 

Commanders  and  their  staff  in  the  conduct  of  deep  operations/air 
land  battle  operations.  Also  utilized  by  the  Joint  Warfare 
Center  for  Joint  Training. 

DESCRIPTION: 

Domain:  Land  and  air;  Naval  operations  are  not  modeled. 

Span :  Accommodates  any  geographic  area  (with  the  exception  of 

Polar  regions)  depending  on  availability  of  terrain  data  base. 
Several  terrain  data  bases  completed  (Central  Europe,  Southwest 
Asia,  Central  America,  Korean  Peninsula);  others  are  in 
preparation. 

Environment :  Hex  based,  with  a  resolution  of  3  km  wide  hexes. 

Models  natural  and  manmade  barriers  (roads,  rivers,  bridges, 
terrain  vegetation,  mine  fields,  contamination,  etc.). 

Force  Composition:  Army  Corps/divisions;  used  also  for  Joint 
and  combined  forces.  Red  and  Blue. 

Scope  of  Conflict:  Conventional,  nuclear,  and  chemical 
warfare.  Models  mid  and  high  intensity  conflict. 

Mission  Area:  Conventional,  nuclear,  and  chemical  missions. 

Level  of  Detail  of  Processes  and  Entities:  System  supports 
Corps/divisions  with  lowest  level  normally  modeled  being 
battalions.  With  split  merge  capability,  modeling  can  go  down  to 
the  individual  personnel  level  if  necessary  (i.e.,  MP,  scout). 
Movement  or  attack/defend/withdraw/delay  directives  can  be  issued 
to  ground  units.  Ground  attrition  results  are  based  on 
Lanchester  Equations,  modified  by  a  rule  based  A/l  system,  and 
results  are  provided  by  individual  attrition  reports  and  display 
or  unit  strength  percentages.  Can  issue  directives  to  individual 
aircraft.  Aircraft  attrition  based  on  probability  of  kill,  with 
groups  of  aircraft  typically  modeled  as  an  entity.  However, 
single  aircraft  can  be  modeled  if  necessary.  All  seven 
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battlefield  operating  systems  (BOS)  are  modeled  (maneuver,  fire 
support,  air  defense,  command  and  control,  intelligence,  mobility 
and  survivability,  and  combat  service  support). 

CONSTRUCTION: 

Human  Participation:  Required  for  decisions  and  processes. 

Time  Processing:  Dynamic,  event  stepped  model.  Progresses 
through  events  at  a  user  specified  ratio  of  exercise  time  to  real 
time . 

Treatment  of  Randomness:  Attrition  determined  based  on 
Lanchester  Coefficients.  The  attrition  results  are  further 
refined  utilizing  a  rule  based  AI  system. 

Sidedness:  Two  sided,  asymmetric,  model  with  both  sides 

reactive . 

LIMITATIONS :  Does  not  model  Naval  operations,  tactics,  or 

warfare.  Does  not  model  biological  warfare.  Does  not  model  low 
intensity  conflict. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Expansion  of  model 
capabilities  (size,  units  portrayed)  and  linkage  to  other  models 
are  under  consideration.  Additionally,  some  functionality 
improvements  are  also  being  considered  (i.e.  Special  Operations 
Forces  play),  providing  enhanced  joint  forces  participation 
and  greatly  increasing  current  capabilities. 

INPUT :  Requires  extensive  data  base  containing  information  about 

weapons  types  and  capabilities,  unit  types  and  initial  locations. 
Graphics  display  system  requires  laser  disk  containing 
terrain/geographic  data.  Operator  input  is  via  computer 
terminals  and  mouse/digit-pad  located  at  each  workstation. 

OUTPUT:  Graphics  display  of  terrain  and  unit  data.  Reports 

generated  as  screen  display  at  computer  terminals  and  as  hard 
copy  printout. 

HARDWARE  AND  SOFTWARE: 

Computer:  Designed  to  run  on  a  DEC  mainframe  (8600,  8650, 

6420)  and  a  network  of  distributed  MicroVAX's  (MVII,  MV3100). 

Storage :  Magnetic  tape  and  disk  storage  media  capability  as 

follows : 

Mainframe:  1.2  Gb  on  disk,  950  Mb  tape,  128  Mb  memory. 

Each  MicroVAX:  540  Mb  on  disk,  95  Mb  on  tape,  1 6  Mb  memory. 
Peripherals :  Typically  42  workstations  per  installation  site, 

with  each  workstation  containing:  3  VT320  terminals,  1  laser 
disk  player,  26  inch  color  monitor,  a  graphics  display 
controller,  a  mouse  or  digit-pad,  and  one  printer. 
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Programming  Language:  SIMSCRIPT  II. 5,  "C" . 

Documentation :  Extensively  documented  with  16  published 

manuals . 

SECURITY  CLASSIFICATION:  UNCLASSIFIED,  but  data  bases  are  often 
classified . 

GENERAL  DATA: 

Data  Base:  Population  of  large  data  bases  can  take  many 
man-months  for  initial  generation. 

CPU  Time  per  Cycle:  Model  is  event  stepped  and  not  time 
stepped.  As  such,  the  cycle  time  is  dependent  on  the  data  base 
size,  the  player  configuration,  and  the  current  activity.  Large 
exercises  can  take  hours  of  CPU  time  to  process  hours  of  combat. 

Data  Output  Analysis:  There  is  no  post  processor  analysis  of 
outputs.  Output  reports  are  generated  during  the  exercise,  and 
analysis  is  done  manually  for  after  action  review  purposes. 
Automated  AAR  is  under  consideration. 

Freguencv  f  Use :  Varies  significantly  by  command,  but  is  used 
approximately  2—20  times  per  year,  per  user  installation  site. 

Users :  I  Corps,  III  Corps,  V  Corps,  VII  Corps,  XVIII  Airborne 

Corps,  Battle  Command  Training  Program  (BCTP),  and  Division  sites 
associated  with  each  Corps  site.  Also  utilized  by  Joint  warfare 
Center . 

Comments:  Managed  through  a  configuration  control  board  (CCB) 

made  up  of  representatives  of  the  user's  and  the  sponsor.  Model 
is  continually  upgraded  based  on  user  needs,  and  based  on 
prioiities  established  by  the  CCB.  PM  TRADE  is  configuration 
Manager . 

Releasabi 1 i tv :  Executable  code  is  available  for  release  if 
coordinated  through  the  CCB.  However,  source  code  cannot  be 
released  due  to  configuration  management  policy. 


TITLE :  CORPS  Support  Artillery  Model  -  COSAM 

DATE  IMPLEMENTED:  30  September  1983. 

MODEL  TYPE:  Analysis. 

PROPONENT :  Systems  Analysis  and  Evaluation  Office,  U.S.  Army 

Missile  Command,  Redstone  Arsenal,  AL  35898-5060. 

POINT  OF  CONTACT:  Nixon  W.  Powell,  DSN  746-3555/(205)  876-3555. 

PURPOSE :  The  COSAM  model  is  a  deterministic  computer  simulation 

of  conventional  combat  at  the  corps  level.  The  primary  purpose 
of  the  COSAM  model  was  to  provide  the  U.S.  Army  Missile  Command 
(MICOM)  with  a  tool  that  could  be  used  to  analyze  the  effects  of 
a  Corps  Support  Weapon  System  (CSWS).  The  model  may  be  used  for 
the  analysis  of:  tactics,  doctrine,  operational  concepts,  force 
structure,  force  design  using  existing  types  of  systems, 
potential  new  types  of  systems,  mobilization  and  reinforcement 
schedules,  and  analysis  of  new  design  alternatives.  Also 
included  as  a  purpose  is  the  analysis  of  some  stockpile  and 
logistic  issues. 

DESCRIPTION: 

Domain:  Land  and  air. 

Span :  Corps,  battalion  and  maneuver  unit  companies. 

Environment :  Electronic  battlefield,  traffic  ability  and 

weather  information. 

Force  Composition:  Mix  of  land  combat  systems  for  both  blue 
and  red . 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Primarily  indirect  fire  ar^’llery  but  also 
includes  maneuver  units  and  effects  of  the  air  battle. 

Level  of  Detail  of  Processes  and  Entities:  Number  of  missions 
and  number  of  rounds  fired.  Attrition  information  for  the 
various  fire  support  means. 

CONSTRUCTION: 

Human  Participation:  Does  not  reguire  human  intervention 
during  the  simulation  of  an  entire  campaign.  Human  participation 
is  not  permitted  except  for  gathering  and  setting  up  input  data. 
Also,  analysis  requires  human  participation. 

Time  Processing:  Dynamic  closed  form. 
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Treatment  of  Randomness:  Deterministic. 


GENERATES  A  VALUE  AS  A  FUNCTION  OF  AN  FXPECTED  VALUE 

Sidedness :  Two-sided,  asymmetric  and  both  sides  reactive. 

LIMITATIONS :  Results  of  rear  area  target  attack  is  limited  to 

attrition.  That  is,  the  effects  of  delays,  disruption,  etc.,  and 
certain  behavioral  aspects  are  not  quantified.  No  explicit 
capability  to  play  the  integrated  battlefield. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  None . 

INPUT:  The  model  inputs  are  categorized  as  high  level  and  lower 

level  inputs.  The  high  level  inputs  consist  of: 

Parameter  File:  Determine  scenario,  select  run 
characteristics,  select  output  desired. 

Arrivals  File:  Selectable  from  the  Parameter  file. 

Binary  Data  File:  No  user  access. 

Lower  Level  Inputs: 

Allowing  user  to  modify  selected  information  in  the  database 
(Binary  Data  File)  at  run  times. 

Weather  information. 

Fire  support  organizational  data. 

Fire  support  candidate  performance  data. 

Fire  support  mission  information. 

OUTPUT :  The  model  consists  of  high  level  and  lower  level 

outputs.  The  high  level  outputs  consist  of: 

A  concise  report  will  be  provided  for  data  of  interest 
concerning  rear  area  loss  attritions  to  various  fire  support 
means . 

The  report  will  include  performance  information  for  fire 
support  means  to  include  the  number  of  missions  and  number 
of  rounds  fired. 

No  high  level  outputs  will  be  provided  concerning  the 
outcome  of  the  front  line  combat,  e.g.,  FEBA  movement,  loss 
exchange  ratios,  etc. 

Lower  Level  Outputs: 

Lower  level  outputs  are  provided  by  the  COSAM  Postprocessor. 
The  outputs  vary  from  loss  summary  to  detailed  information 
on  each  direct  fire  engagement. 

These  outputs  are  not  normally  of  interest,  but  should  be 
available  to  answer  detailed  questions. 

HARDWARE  AND  SOFTWARE: 

Computer  ( OS ) :  CDC  cyber  74. 

Operating  System:  NOS /BE. 

Storage :  200K  minimum,  60  byte  word. 

Peripherals :  Line  printer,  magnetic  disks  and/or  tape  drives. 
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Programming  Language:  FORTRAN  IV. 

Documentation;  Users  manuals  were  published  by  Vector  Research 
Incorporated.  The  first  manual  is  dated  31  December  1981  and  the 
last  updated  manual  is  dated  30  September  1983. 

SECURITY  CLASSIFICATION:  The  program  itself  is  UNCLASSIFIED 
unless  it  is  labeled.  (Labeling  here  means  identifying  the 
weapon  systems  and  rounds  used  as  well  as  the  scenario  used). 

GENERAL  DATA: 

Preparation :  Time  required  to  gather  data  is  unpredictable. 

Time  to  set  up  data  in  proper  formats  might  run  as  much  as  a  week 
to  two  weeks,  if  starting  from  scratch.  If  one  is  only  making 
modifications  to  an  existing  set  of  data,  it  should  require  only 
hours  or  days  rather  than  weeks . 

CPU  Time  per  Cycle:  The  program  itself  is  completely 
computerized  and  run  time  depends  upon  the  complexity  of  the 
problem.  Generally  CPU  time  per  combat  day  would  be  1-3  minutes. 

Data  Output  Analysis:  The  time  for  analysis  obviously  depends 
on  the  number  of  different  variables  considered  in  the  analysis. 

A  week  or  more  is  usually  required. 
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TITLE :  Countermine  Combat  Model  -  COUNTERCOM 


DATE  IMPLEMENTED:  1980. 

PROPONENT :  LJ.S.  Army  Bel  voir  Research,  Development,  and 

Engineering  Center,  Ft.  Belvoir,  VA  22060-5606. 

POINT  OF  CONTACT:  Keith  Dugas,  Advanced  Systems  Concepts  Office 
DSN  354-2095/Comm  (703)  664-2095. 

PURPOSE:  COUNTERCOM  was  developed  to  realistically  model,  at 

a  very  high  level  of  resolution  (i.e.,  individual  weapon 
systems),  tank/anti-tank  combat;  air- to-surf ace  and  surface- 
to-air  engagements;  the  effects  of  indirect  artillery  and 
mortar  fire  (including  obscuration  and  suppression);  tactical 
maneuver  and  fire  plans;  the  direct  and  indirect  effect  of  land 
mines  and  other  obstacles;  and  countermine/counter-obstacle 
systems.  Besides  the  applications  of  mobility/counter-mobility 
systems  within  the  framework  of  the  modern,  integrated  battle¬ 
field. 

DESCRIPTION: 

Domain :  Land  and  Air. 

Span :  Accommodates  any  region  depending  on  data  base;  one 

database  scenario  completed  but  outdated. 

Environment :  Grid-squares.  Models  transportation  barriers. 

Uses  intervisibilities  of  defender/attacker  path  pairs. 

Force  Composition:  Combined  forces,  Blue  and  Red. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Close  air  support,  indirect  artillery. 

Level  of  Detail  of  Processes  and  Entities:  High  resolution; 
can  model  individual  units,  systems.  Intelligence  and 
communications  modeled.  Attrition  are  based  on  probabilities, 
Monte  Carlo  for  individual  units. 

CONSTRUCTION: 

Human  Participation:  Not  required.  Human  participation  not 
permitted  once  execution  begins. 

Time  Processing:  Dynamic,  time-step. 

Treatment  of  Randomness :  Stochastic,  Monte  Carlo. 

Sidedness :  Two-sided,  asymmetric,  both  sides  reactive. 
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fixed  attack  paths,  has  not 


LIMITATIONS :  Stationary  defenders, 

been  updated  since  1980. 

PLANNED  IMPROVEMENTS /MODIFICATIONS :  None . 

INPUT:  Scenario  (area  of  interest,  obstacles,  terrain 

intervisibility),  defensive  types,  defensive  positions,  air 
defense  types,  offensive  types,  sensor  reconnaissance  routes, 
tactics  tables,  probabilities,  indirect  fire  systems,  unit  paths. 

OUTPUT :  Ground  truth  map,  input  data,  battlefield  perception 

map,  lane  availability  map  (for  minefields),  maneuver  tactics 
selected,  results  file  (list  of  events  simulated),  graph  of 
survivors  vs  time,  offensive  and  defensive  casualty  summaries, 
m-kills,  k-kills,  percent  survivors  by  type. 

HARDWARE  AND  SOFTWARE: 

Computer:  CDC  CYBER  6000  series,  NOS/VE  OS. 

Storage :  Minimum  75K. 

Peripheral :  Graphics  printer,  batch  or  interactive  terminal. 

Programming  Language:  FORTRAN  4  Extended,  with  some  routines 
in  COMPASS  3. 

Documentation :  Available  form  DTIC,  2  Vols,  ADB061097L. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED,  data  bases  can  be 
classified . 

GENERAL  DATA: 

Data  Base:  6  man-months  for  new  data  base. 

Data  Input:  1  man-week  to  structure  input  into  model. 

CPU  Time  per  Cycle:  About  10  seconds  per  cycle. 

Data  Output  Analysis:  1-2  days. 

Frequency  of  Use:  Infrequent. 

Users :  BRDEC . 

Comments :  Has  not  been  updated  to  include  new  scenario, 

weapons  data,  probabilities  in  recent  times. 

Releasabilitv:  Only  to  U.S.  Government  agencies. 
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TITLE :  DE  Combat  Simulation  -  DECSIM 


DATE  IMPLEMENTED:  Oct  1984. 

MODEL  TYPE :  Analysis. 

PROPONENT :  WS6  Division,  RARDE,  Fort  Halstead,  Sevenoaks,  Kent. 

DEVELOPER:  WS6  Division,  RARDE,  and  SD  Scicon  Ltd. 

POINT  OF  CONTACT:  S/WS6  Division,  RARDE,  0959  32222  x2381 . 

PURPOSE:  Research  and  Evaluation  tool  for  the  assessment  of 

system  and  subsystem  performance. 

DESCRIPTION :  Land  and  low-level  air  domain;  local  engagement; 

digitized  terrain;  explicit  lines-of-sight ;  two  conventional, 
company-sized,  mixed  forces  of  armored  fighting  vehicles,  direct- 
fire  anti-tank  guided  weapons,  anti-tank  helicopters  and  novel 
weapons;  detailed  representation  of  vehicles  systems,  sub¬ 
systems,  crew  activities,  weapon  system  engagement  sequence, 
target  acquisition. 

CONSTRUCTION :  Non-interactive,  non-interruptible ;  event-stepped; 

stochastic  Monte  Carlo;  two-sided  asymmetric  non-reactive. 

LIMITATIONS :  Number  of  Units  limited  to  40  for  normal  use; 

combat  area  limited  to  6km  by  5km  for  ground  forces,  10km  by  8km 
for  helicopters. 

INPUT :  Digitized  terrain  data  (based  on  DLMS  Level  2);  equipment 

performance  data  (mobility,  weapon  characteristics)  from  MoD  R&D 
Establishments;  crew  rules. 

OUTPUT :  Statistically  analyzed  data  on  system  and  sub-system 

performance . 

HARDWARE  AND  SOFTWARE:  VAX  8350  and  VAX  Il/GPX  with  VMS;  2  Mbyte 
main  memory  required  for  terrain  database  image;  PASCAL; 
documentation  April  1991. 

SECURITY  CLASSIFICATION:  Confidential  UK/US  Eyes  Only  (without 
data )  . 

CPU  REQUIREMENTS :  4  hours/rep  (40  units,  10  minute  engagement, 

VAX  8350  )  . 

FREQUENCY  OF  USE:  Continuous. 

USERS :  WS6  Division,  RARDE. 
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TITLE :  Directed  Microwave  Energy  Weapon  Simulation  -  DMEWS 


DATE  IMPLEMENTED:  September  1987. 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.S.  Army  Materiel  Systems  Analysis  Activity  (AMSAA) . 

POINT  OF  CONTACT:  Director,  USAMSAA,  ATTN:  AMXSY-CS 

(Mr.  Mike  Deckert),  Aberdeen  Proving  Ground,  MD  21005-5071, 

Av  298-6675/Comm  301  278-6475. 

PURPOSE :  A  research  and  evaluation  tool  used  at  the  component 

level  during  system  development  to  estimate  the  effect  of  a  high 
power  microwave  pulse  on  various  electric  systems  or  subsystems. 
The  source  and  its  output  characteristics  are  considered  as  well 
as  atmospheric  propagation,  coupling  to  and  location  of  various 
entry  points  on  a  target,  emission  losses  between  the  entry  point 
and  component,  component  coupling,  and  the  target  path.  The 
primary  measure  of  effectiveness  provided  by  the  model  is 
probability  of  component  failure  as  a  function  of  range  and 
engagement  time.  DMEWS  is  a  digital,  one-on-one  engagement  model 
between  ground  or  air  targets  and  a  Directed  Microwave  Energy 
Weapon  (DMEW) .  The  engagement  dynamics  include  probability 
theory  and  a  version  of  the  AMSAA  INCURSION  model  which  has  been 
modified  by  replacing  the  air  defense  gun  routine  with  microwave 
weapon  routines. 

DESCRIPTION: 

Domain:  Land  and  air. 

Span :  Individual  component. 

Environment :  Existence  of  line-of-sight  is  assumed. 

Force  Composition:  Individual  component. 

Scoper  of  Conflict:  Any. 

Mission  Area:  Counter  to  weapons  or  platforms  that  contain 
electrical  circuits. 

Level  of  Detail  of  Processes  and  Entities: 

Entity :  System  component  or  subsystem. 

Processes :  Degrades  or  kills  electrical  circuits. 

CONSTRUCTION: 

Human  Participation:  Not  permitted. 

Time  Processing:  Static,  single-pulse  model. 
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Treatment  of  Randomness:  Stochastic,  direct  computation. 
Sidedness :  One-sided. 


LIMITATIONS :  Single  pulse  probability  only;  Limited  database  at 

higher  frequencies. 

INPUT:  Microwave  Generator  Characteristics;  Antenna 

Characteristics;  Atmospheric/Meteorological  conditions;  Entry 
Point  Characteristics  and  Location;  Target  Component 
Characteristics;  Engagement  Parameters. 

OUTPUT :  Time;  Range;  Power  Density;  Accessibility;  Access 

Angles;  Probability  of  damage  of  each  susceptible  Component. 

HARDWARE  AND  SOFTWARE: 

Computer  (OS):  IBM  PC  (DOS). 

Storage  required:  640K. 

Peripherals :  None . 

Programming  Language:  FORTRAN  77. 

Documentation :  Available.  DDC  Accession  Number:  None. 

SECURITY  CLASSIFICATION:  (Model  without  data)  UNCLASSIFIED. 
GENERAL  DATA: 

Database:  N/A  (time  required  to  prepare). 

CPU  Time  per  Cycle:  2  seconds. 

Data  Output  Analysis:  Analyst  dependent. 
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TITLE :  Direct  Fire  Stand-Alone  Model  -  DFSAM 


DATE  IMPLEMENTED:  1985. 

MODEL  TYPE:  Analysis. 

PROPONENT :  CA4  Division,  RARDE,  Fort  Halstead. 

POINT  OF  CONTACT:  N.  Roberts,  RARDE,  ext  2289. 

PURPOSE :  Research  and  Evaluation  of  weapon  systems 

effectiveness . 

DESCRIPTION: 

Domain:  Land. 

Span :  Local  (typically  up  to  20km  front). 

Environment :  Digitized  terrain,  representing  relief, 

vegetation  and  man-made  cover,  500m  resolution. 

Scope :  Conventional. 

Mission  Area:  Direct  fire  battle. 

Level  of  Detail:  Company  (Red)  vs  Troop  (Blue).  High-value 
units  (e.g.  LRGW )  may  be  represented  individually.  Lanchester- 
based  attrition.  Movement  is  along  preplanned  routes,  at  speed 
governed  by  local  going. 

CONSTRUCTION: 

Human  Participation:  Not  required,  but  is  permitted. 

Time  Processing:  Partially  time-sliced,  partially  event 
sequenced . 

Treatment  of  Randomness:  Stochastic,  Monte  Carlo. 

Sidedness :  Two-sided,  symmetric. 

LIMITATIONS :  No  infantry.  No  C3I. 

PLANNED  IMPROVEMENTS :  None . 

INPUT :  Weapon  characteristics  (range,  time  of  flight);  Minefield 

and  barrier  data  (location,  mine  density,  etc.);  Order  of  Battle, 
deployment,  routes,  orders;  Systems  data  (DF  SSKP  data,  minefield 
lethality,  artillery  lethality). 

OUTPUT :  Killer/victim  tables,  by  replication  and  averaged;  Mine 

and  artillery  kills. 
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HARDWARE  AND  SOFTWARE: 

Computer/OS:  VAX/ VMS. 

Storage :  20  Mb  (40000  blocks). 

Peripherals :  Requires  DEC  VT100,  VT200  or  VT300  compatible 

terminal . 

Language :  FORTRAN  77. 

Documentation :  User's  guide,  Programmers's  guide. 

CLASSIFICATION;  UNCLASSIFIED. 

GENERAL  DATA: 

Data  Preparation:  Several  weeks. 

Preprocessor :  Few  CPU  minutes. 

Simulation :  Approx  one  minute  CPU  time  per  minute  of  battle. 

Analysis  Package:  Minimal.  NB  timings  are  based  on  a  complex 
main  defensive  action  scenario. 

Freguencv  of  Use:  Rare. 

Users :  CA4  Division  RARDE . 

Comments :  DFSAM  uses  the  same  DF  modelling  as  the  Divisional 

War  Game  (DWG)  from  CA3,  RARDE,  and  was  originally  intended  to  be 
used  to  replicate  small  elements  of  the  DWG  campaign  and  DFSAM 
normally  uses  systems  data  files  created  for  DWG  use.  It  is 
intended  that  the  modelling  link  between  the  two  models  be 
maintained . 
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TITLE :  Divisional  War  Game 


DWG 


DATE  IMPLEMENTED:  1975. 


MODEL  TYPE:  Analysis. 

PROPONENT :  CA3  Division,  RARDE,  Sevenoaks,  Kent. 

POINT  OF  CONTACT:  Dr.  I.  P.  Gibson,  0959  32222  ext  2451. 

PURPOSE :  A  research  and  evaluation  tool  primarily  concerned  with 

examining  the  use  of  proposed  weapon  systems  but  also 
contributing  to  the  analysis  of  concepts  of  operations. 

DESCRIPTION: 

Domain :  Land,  with  representation  of  air  operations  in  less 

detail . 

Span :  Corps. 

Environment :  Terrain  and  cultural  features  represented  to  500m 

resolution.  Meteorological  effects  vary  with  time  of  day. 

Force  Composition:  All  arms,  but  with  less  attention  paid  to 
direct  fire  systems  than  to  others. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Corps  and  division  level  systems. 

Level  of  detail  of  processes  and  entities:  The  lowest  entity 
modelled  is  generally  a  troop,  but  some  high  value  equipments  are 
represented  as  individual  vehicles.  Attrition  is  represented  in 
most  detail  for  indirect  fire  and  AH;  movement  and  engagement  are 
a  player's  discretion  constrained  by  the  rules  of  the  game. 
Communications  between  players  simulate  the  net  structure  of  the 
force . 

CONSTRUCTION: 

Human  Participation:  Is  required  for  decisions,  without  which 
the  game  would  run  but  not  make  sense.  Multiple  command  levels 
are  explicitly  represented. 

Time  and  Processing:  Dynamic,  event  step. 

Treatment  of  Randomness:  Stochastic,  Monte  Carlo. 

Sidedness:  Two-sided,  symmetric. 

LIMITATIONS :  Numbers  of  individual  units  less  than  4000  each 

side.  Rate  of  play  typically  10-15  minutes  real  time  to  1  minute 
combat  time. 
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PLANNED  IMPROVEMENTS /MODIFICATIONS :  Continually  updated  to 
incorporate  new  systems.  Much  of  the  software  is  being 
reimplemented . 

INPUT:  ORBAT,  opening  deployment,  equipment  characteristics. 

OUTPUT :  Controllers'  report;  data  appropriate  to  study  topics. 

An  archive  of  past  series  is  maintained  from  which  data  are 
provided  for  a  wide  range  of  studies. 

HARDWARE  AND  SOFTWARE: 

Computer :  Dec  8810,  VAX/VMS  (dedicated). 

Storage :  CPU:  128  Mbyte,  disk:  3  Gbyte. 

Peripherals :  6  Sigmex  graphics  terminals,  2  micro  VAX  II,  30- 

40  VDUs;  20-25  printers,  2  line  printers,  2  magnetic  tape  drives; 
10  Macintosh  Ilci  graphics  workstations. 

Programming  Language:  VAX  FORTRAN,  to  be  reimplemented  in  C. 
Documentation :  Functional  specification. 

SECURITY  CLASSIFICATION:  Restricted. 

GENERAL  DATA 

Data  Base:  20-30  days,  including  deployment  of  units  using 
Macintosh  graphics  workstation. 

CPU  Time  per  Cycle:  Dependent  on  phase  of  battle  (i.e.  number 
of  units  in  play  and  their  activities).  In  practice,  cpu  time  is 
less  critical  than  the  players  in  determine  game  speed. 

Data  Output  Analysis:  An  extensive  relational  database  is 
created  for  each  game  and  used  to  derive  statistical  and  other 
information  on  weapon  system  performance.  The  database  is 
implemented  in  RdB  (full  supporting  documentation  is  available). 

Freguencv  of  Use:  A  series  of  five  games  (each  lasting  one 
month)  is  played  each  year,  plus  occasional  extra  activities. 

Users :  RARDE . 

Comments :  A  replay  facility  is  available  for  limited 

replication  and  parametric  variation. 
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TITLE :  Division  Level  War  Game  Model  -  DIVLEV 

DATE  IMPLEMENTED:  1969. 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.S.  Army  Materiel  Systems  Analysis  Activity. 

POINT  OF  CONTACT:  Director,  USAMSAA,  ATTN:  AMXSY-CC,  Tony  Rouse, 
Aberdeen  Proving  Ground,  MD  21005-5071,  AV  298-5771/301  278-5771. 

PURPOSE :  A  research  and  evaluation  tool  used  during  system 

development  and  to  estimate  system  effectiveness. 

DESCRIPTION :  DIVLEV  is  both  a  stand-alone  combat  simulation  and 

man-in-the-loop  war  game.  The  methodology  has  been  calibrated 
through  comparisons  with  historical  battle  results.  The  model 
was  developed  to  produce  realistic  tactical  situations, 
accounting  for  the  environment  and  capabilities  of  opposing 
forces,  and  including  unit  orders,  optional  contingency  orders, 
movements  and  attrition  as  a  function  of  time.  These  situations 
are  used  in  the  evaluation  of  various  item  level  materiel  systems 
and  in  evaluations  of  weapon  mixes.  The  resolution  of  units  that 
the  players  control  is  usually  determined  by  the  objective  of  the 
study  and  the  tactics  the  players  intend  to  use.  Generally,  the 
player-controlled  units  are  of  battalion  or  company  size.  DIVLEV 
is  structured  so  that  players  control  the  organization  for 
combat.  They  can  use  either  standard  TO&E  units  or  task  forces, 
and  these  units  can  be  at  either  full  or  reduced  strength.  The 
players  give  orders  and  optional  orders  to  each  unit  which 
include  the  route  the  unit  is  to  take,  the  unopposed  speed  at 
which  it  is  to  move,  the  dimensions  of  the  unit  (whether  deployed 
or  in  column),  and  the  direction  the  unit  is  to  face  upon 
reaching  its  destination.  Optional  orders  are  activated  when 
player  described  conditions  are  met.  Once  an  optional  order  is 
activated,  the  old  order  is  discarded  and  the  unit  starts  on  its 
new  assignment.  DIVLEV  contains  a  representation  of  suppression 
by  both  direct  and  indirect-fire  weapons,  a  treatment  of  system 
reliability,  and  a  representation  of  close  air  support. 
Suppression  effects  are  based  on  combat  experience.  Target 
acquisition  is  played  explicitly.  The  time  step  is  variable. 

Once  sets  of  player-generated  contingency  orders  have  been 
developed,  the  model  can  be  used  as  a  combat  simulation.  In  this 
mode,  the  same  player  inputs  are  used,  but  different  weapon 
characteristics,  artillery  target  priorities,  sensor  mix, 
artillery  attack  criteria,  and  so  forth  can  be  input.  This 
feature  allows  for  the  parametric  evaluation  of  weapon  and 
support  systems,  doctrine,  and  trade-offs  among  them  in  terms  of 
force  success. 

Domain:  Land  and  air. 

Span :  Regional. 


Environment :  Terrain  relief,  mobility  characteristics  and 

cultural  features,  weather,  and  time  of  day. 

Force  Composition:  Combined  forces. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Tactical  combined  arms. 

Level  of  Detail  of  Processes  and  Entities: 

Entity :  Blue  Division,  Red  Army. 

Processes :  Movement,  target  acquisition,  command  and 

control,  attrition,  suppression. 

CONSTRUCTION: 

Human  Participation:  Optional,  for  decisions,  and  if  there  is 
human  participation  the  model  is  designed  to  be  interrupted  for 
the  introduction  of  a  new  set  of  decisions. 

Time  Processing:  Dynamic,  time  step. 

Treatment  of  Randomness :  Deterministic. 


Sidedness :  Two-sided. 

LIMITATIONS :  Unit  logistics  are  recorded,  not  individual  weapon 

PLANNED  IMPROVEMENTS /MODIFICATIONS :  Effort  is  underway  to 
improve  real-time  visual  displays  and  pre-  and  post-game 
processing . 

INPUT :  Tactical  scenario--initial  situation  and  unit  objectives; 

Weapon  data--range,  rate  of  fire,  crew  siz.e,  weight  of 
ammunition,  and  range  dependent  kill  rates;  Terrain  statistics, 
wooded  and  urban  areas;  Unit  data  to  include  position,  equipment 
strength  and  maneuver  instructions;  Vehicle  speeds. 

OUTPUT :  Plots  showing  unit  position;  Unit  data  to  include  unit 

position,  strength,  and  interaction  with  opposing  units; 

Killer- victim  scoreboard;  The  time  interval  for  any  of  the  output 
can  be  specified  by  input  codes. 

HARDWARE  AND  SOFTWARE: 

Computer  (OS):  SUN  (UNIX),  VAX  11/785  (VMS  and  UNIX). 

Storage  required:  150K. 

Peripherals :  Disc  storage,  tape,  printer,  video,  work 

stations . 

Programming  Language:  FORTRAN  77. 

Documentation :  "DIVLEV  War  Game  Computer  Program,"  USAMSAA, 

January  1977. 
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SECURITY  CLASSIFICATION:  (Model  without  data)  UNCLASSIFIED. 
GENERAL  DATA: 

Database :  Four  man-months  for  initial  development.  Division 

vs.  Army;  three  man-months  for  weapon  and  other  system,  and 
terrain  data. 

CPU  Time  per  Cycle:  SUN,  simulation  mode,  two  hours  per  24 
hours  of  simulated  combat;  SUN,  war  game  (man-in-the-loop)  mode, 
15  minutes  per  one  hour  game  step. 

Data  Output  Analysis;  One  week  per  variation  from  initial 
game,  plus  one  month  after  last  variation  for  summaries. 
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TITLE:  ELAN  Plus  (ELAN+) 

MODEL  TYPE:  Analysis 

PROPONENT:  TRADOC  Analysis  Command  -  White  Sands  (TRAC-WSMR) ,  White 
Sands,  m  88002-5502 

POINT  OF  CONTACT:  Dr.  H.  M.  Sassenfeld,  1RAC-WSM*,  ATRC-W,  WSMR,  fW 
88002-5502,  DSN:  258-1615,  Commercial  (505)  678-1615. 

PURPOSE:  Weapon  effectiveness  analysis,  terrain,  scenario  and  tactical 
analysis  training. 

DESCRIPTION:  ELAN+  is  a  medium  resolution,  two-sided,  event  sequenced, 
deterministic/stochastic  combat  model  for  brigade  and  battalion  level. 
Combat  activities  modeled  are  maneuver,  acquisition,  direct  fire,  fire 
support,  smart  munitions,  mines,  smoke,  and  weather.  Actions  and 
reactions  can  be  triggered  ( specif iably)  for  maneuver,  fire,  terrain,  and 
other  environment,  interactively  driven  by  menus  and  graphics.  Extensive 
analysis  capability  of  digital  terrain. 

LIMITATIONS :  Brigade  level;  no  logistics;  no  explicit  ojnnunicaticns 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  Dismounted  infantry,  Air  Defense 

INPUT:  Routes  of  forces,  forced  (specifiable  by  unit  and  task  force), 
maneuver  and  fire  support  schedules,  weapon  performance  data  (from  AMSAA 
data  derived  values )  from  video  terminal;  weapon  performance  data  from 
tape;  Digital  terrain. 

OUTPUT:  In  graphics  and  print:  scenario,  measures  of  effectiveness  (70Es) 
hierarchical  force  diagram. 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS) :  Hewlett  Packard  9000  series;  UNIX,  HPBasic 
STORAGE:  8  MB  RAM 

PERIPHERALS:  Hard  disk,  printer,  color  monitor 
PROGRAMMING  LANGUAGE:  HPBasic,  PASCAL 
DOCUMENTATION:  Available 
SECURITY  GLASSIFICATION:  UNCLASSIFIED 
GENERAL  DATA  AND  TIME  REQUIREMENTS: 


COMMENTS:  Government  agencies  can  obtain  ELAN+  with  a  signed 
memorandum  of  agreement.  Government  Contractors  with  a  valid  contract 
requiring  the  use  of  ELAN+  can  also  obtain  the  model  with  the  approval  of 
the  TRAC  Canranding  General.  Inquiries  for  obtaining  the  model  and 
supporting  data  bases  should  be  addressed  to  TRAC -TOD,  Ft.  Leavenworth,  KS 
66027-5200  or  calling  AV  552-5511  or  ccrrmercial  913-684-5511. 


TITLE:  Error  Analysis  -  ERAN  Model  DATE  IMPLEMENTED:  1988. 

MODEL  TYPE :  Analysis. 

PROPONENT :  HQCECOM,  Attn:  AMSEL-PL-SA,  Ft  Monmouth,  NJ  07703-5000 

POINT  OF  CONTACT:  Edwin  Goldberg,  AV  992-3646/(201)  532-1878. 

PURPOSE :  Research  and  Evaluation  tool  to  enable  an  analyst  to 

use  the  ERAN  to  perform  an  error  analysis  of  a  line-of-bearing 
(LOB)  target  location  system  using  multiple  ellipse  techniques. 

DESCRIPTION: 

Domain :  Any  combination  of  the  identified  items. 

Span :  Local. 

Force  Composition:  Component,  element. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Air,  land  and  sea. 

CONSTRUCTION: 

Human  Participation:  Required  for  input  data. 

Time  Processing:  Model  is  static. 

Treatment  of  Randomness:  Stochastic;  direct  computation. 

Sidedness :  One-sided. 

LIMITATIONS :  Single  target. 

PLANNED  IMPROVEMENTS /MODIFICATIONS :  None . 

INPUT :  Angle  measurement  error  of  sensor  and  other  data 

identified  in  the  31  May  88  user's  guide  and  program 
documentation . 

OUTPUT :  Statistically  analyzed  data  and  other  analysis  (see  31 

May  88  user's  guide  and  program  documentation). 

HAKLmARE  AND  SOFTWARE: 

Computer :  Any . 

Storage:  Minimal  storage  required. 

Peripherals :  Printer. 

Programming  Language:  FORTRAN. 
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Documentation :  The  ERAN  model  documentation  includes  a  user's 

guide  and  program  documentation  manual  which  is  located  at  the 
CECOM  Program  Analysis  and  Evaluation  Directorate,  Fort  Monmouth, 
NJ. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED. 

GENERAL  DATA: 

Data  Base:  N/A. 

CPU  Time  per  Cycle:  Negligible. 

Data  Output  Analysis:  Computer  output  is  self  instructive  and 
complete . 

Frequency  of  Use:  Currently  in  use. 

Users :  CECOM  Center  for  Electronic  Warfare/Reconnaissance 

Surveillance  and  Target  Acquisition,  Fort  Monmouth,  NJ. 

Releasabilitv :  Releasable  to  Govt  only. 
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TITLE :  Evaluation  of  Air  Defense  Effectiveness  -  EVADE  II 

DATE  IMPLEMENTED:  June  1969. 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.S.  Army  Materiel  Systems  Analysis  Activity, 

Aberdeen  Proving  Ground,  MD  21005-5071. 

POINT  OF  CONTACT:  Wyoming  Paris/Everett  White,  AV  298-6382/84. 

PURPOSE :  The  EVADE  model  is  used  to  evaluate  the  survivability 

and  ef fectiveness  of  aircraft  and  aircraft  systems,  and  the 
effectiveness  of  air  defense  weapons,  countermeasures,  tactics 
and  techniques.  It  is  a  deterministic  model  that  evaluates  fixed 
and  rotary-wing  aircraft  in-scenario,  in  combat  with  an  array  of 
ground  air  defense  gun  and  missile  systems  utilizing  digitized 
terrain.  Aircraft  fly  predetermined  paths  over  prepositioned 
weapons  systems.  EVADE  II  is  a  research  and  evaluation  tool  that 
permits  study  of  air  vehicle  interactions  with  air  defense  gun 
and  missile  systems. 

DESCRIPTION: 

Domain :  Ground-to-air  and  air-to-ground. 

Span :  Regional,  limited,  or  local  arena. 

Environment :  Digitized  terrain  (cities,  forest,  orchards,  high 

grass,  bare  earth),  signatures  function  of  weather  and  lighting, 
ECM. 

Force  Composition:  Multiple  aircraft  and  multiple  ground 
weapon  systems. 

Scope  of  Conflict:  Conventional  Red  and  Blue  weapons  systems. 

Mission  Area:  Anti-armor,  close  air  support,  airlift,  direct 
fire  weapons. 

Level  of  Detail  of  Processes  and  Entities:  Calculates  the 
probability  of  Attrition  Kill,  Forced  Landing,  and  Mission  Abort 
as  well  as  aircraft  and  troop  losses  for  air  participants; 
mobility,  firepower,  and  combined  mobility-fire  power  damage 
levels  for  ground  targets. 

CONSTRUCTION: 

Human  Participation:  Not  required. 

Time  Processing:  Dynamic  with  time  steps. 

Treatment  of  Randomness:  Expected  value  deterministic. 
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Sidedness :  Two-sided  symmetric. 


LIMITATIONS :  Fixed  flight  paths  for  a  given  run,  maximum  of  32 

aircraft  independent  paths  (with-out  changing  dimensions), 
maximum  1000  ground  weapon  systems,  no  continuous  movement  of 
ground  systems  (multiple  "snapshots"  are  used). 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Incorporated  of  Air 
Defense  Network  (ADNET),  Command,  Control  Communication, 
Intelligence,  Prioritization  (C3IP)  Links,  KM2  Grid  (read-in 
optimization)  in  Terrain  Database. 

INPUT:  Interactive  input  routine,  Ground  weapon  characteristics 

and  location,  aircraft  characteristics  (flight  path,  weapon 
systems,  vulnerable  areas,  speed,  etc.),  digitized  terrain  (with 
vegetation)  DMAHTC ,  radar  detection,  countermeasures  (warning 
receivers,  jammers),  SAM  Pk's,  aircraft  signatures. 

OUTPUT:  Time  history  of  engagement  (firings  and  subsequent  kill 

damage,  etc),  assessment  of  air  and  ground  losses,  number  of 
rounds  and  missiles  fired,  dynamic  graphics  mission  portrayal. 

HARDWARE  AND  SOFTWARE: 

Computer:  Alliant,  CRAY  XMP,  CRAY  II,  Interactive  EVADE  Input 

Routine,  Dynamic  Graphics  Output  Routine. 

Storage :  Program:  Approx.  677  kilobytes. 

Peripherals :  Graphics  terminal,  PC  for  interactive  version. 

Program  Language :  FORTRAN . 

Documentation :  Users  manuals  available. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED.  Interactive  run  setup 
program  being  developed.  Model  and  database  are  SECRET. 

GENERAL  DATA: 

Data  Base:  Dependent  on  available  input  data  -  1  day  to  2 
weeks . 


CPU  Time  per  Cycle:  Dependent  on  data  base  size  and  player 
configuration.  Large  exercises  can  take  5  hrs  of  CPU  time. 


Data  Output  Analysis:  5  mins  to  5  hrs  depending  on  level  of 
analysis  and  desired  complexity  of  scenario. 


Users : 
Aberdeen 
IN;  CIA. 


Past  users  include  AVRADCOM,  St.  Louis,  MO;  AMSAA, 
Proving  Ground,  MD;  Ketron  Inc.,  Towson,  MD;  MAD,  Crane, 
Currently  AMSAA  and  Ketron  are  active  users. 
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TITLE :  Extended  Directed  Energy  Combat  Simulation  -  EDECSIM 

DATE  IMPLEMENTED:  1989. 

MODEL  TYPE:  Analysis. 

PROPONENT :  CA4  Division,  RARDE  Fort  Halstead,  Sevenoaks, 

England . 

POINT  OF  CONTACT:  Mr.  D.  F.  Wardleworth,  0959  32222  ext  3388. 

PURPOSE :  Study  of  effectiveness  of  conventional  and  novel  DF 

weapons  and  smart  munitions. 

GENERAL  DESCRIPTION: 

Domain :  Land;  representation  of  rotary  wing  aircraft  and  low 

level  air  defence  under  development. 

Span :  There  is  no  hard  upper  limit  terrain  size  nor  on  numbers 

of  units  represented.  Several  hundred  units  on  an  area  20km 
square  have  been  studied. 

Development :  Terrain  height  and  vegetation/building  cover  are 

modelled  to  a  horizontal  resolution  of  100m.  Obscuration,  poor 
visibility  and  TI  sensors  can  be  represented  but  pyrotechnic 
illumination  and  other  night  viewing  enhancements  are  not 
currently  modelled. 

Force  Composition:  EDECSIM  is  2-sided  and  represents  the 
essential  characteristics  of  vehicle  borne  and  certain  dismounted 
weapons.  Infantry  and  fixed  wing  aircraft  are  not  represented. 

Scope  of  Conflict:  Conventional  weapons;  other  systems  may  be 
accommodated  by  program  modification  if  suitable  data  is 
available . 

Mission :  Normal  study  parameters  include  attrition;  assessment 

of  assault  success  and  enemy  observation  are  also  possible. 

Level  of  Detail:  Individual  vehicles  are  represented  and  a 
variety  of  surveillance  and  engagement  tactics  can  be  selected. 
Vehicle  routes  are  pre-specif ied  although  a  limited  number  of 
responses  to  battle  development  are  possible.  Smart  munition 
missions  are  controlled  by  an  autonomous  module  which  deduces 
viable  targets  from  observer  reports;  this  module  includes 
limited  representation  of  communications.  Obscuration, 
conventional  artillery  and  minefields  are  represented  implicitly. 

CONSTRUCTION: 

Human  Participation:  None,  but  scenarios  are  based  on  man-in- 
the-loop  wargames. 
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Time  Processing:  Event-sequenced. 

Treatment  of  Randomness:  Stochastic. 

Sidedness :  Two-sided,  sides  are  interchangeable  with  no  limits 

on  size  apart  from  overall  constraints. 
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TITLE :  Fire  Support  Command  and  Control  Analysis  Tool  -  FISCCAT 

DATE  IMPLEMENTED:  1987. 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.S.  Army  Materiel  Systems  Analysis  Activity. 

POINT  OF  CONTACT:  Director,  USAMSAA,  ATTN:  AMXSY-CC 

(Mr.  Peter  Norman),  Aberdeen  Proving  Ground,  MD  21005-5071, 

AV  298-6541 /Comm  301-278-6541. 

PURPOSE :  A  research  and  evaluation  tool  for  use  during  system 

development  and  to  estimate  system  effectiveness.  The  FISCCAT 
model  was  designed  to  aid  in  the  evaluation  of  the  item  level 
performance  of  the  Advanced  Field  Artillery  Tactical  Data  System 
( AFATDS ) .  It  focuses  on  the  message  processing  required  within 
the  fire  execution  mission. 

DESCRIPTION :  FISCCAT  is  a  one-sided,  discrete  events  simulation. 

The  stimulus  for  the  model  is  a  list  of  targets  of  opportunity. 
FISCCAT  was  designed  with  flexibility  in  mind  --  both  force 
structure  and  network  characteristics  c?.n  be  easily  changed  to 
examine  different  configurations  of  artillery  command  and 
control . 

Domain :  Land. 

Span :  Regional  (any  region). 

Environment :  Not  applicable. 

Force  Composition:  Artillery  command  and  control  within  a 
maneuver  brigade  supported  by  a  Direct  Support  Battalion. 

Scope  of  Conflict:  Any  level  that  includes  artillery  command 
and  control . 

Mission  Area:  Indirect  artillery  command  and  control  and 
sensors . 

Level  of  Detail  of  Processes  and  Entities: 

Entity :  Artillery  command  and  control  within  a  maneuver 

brigade  supported  by  a  Director  Support  battalion. 

Processes :  Targets  introduced  into  the  simulation  trigger 

message  traffic  by  the  node  that  "acquires"  the  target. 
Subsequent  message  traffic  results  as  the  target  is  processed. 
While  the  model  accounts  for  representative  time  for  batteries 
to  fire  missions,  the  model  does  not  include  the  results  of 
weapon  fire  and  so  provides  measures  of  performance  rather  than 
effectiveness . 
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CONSTRUCTION: 

Human  Participation:  Not  permitted. 


Time  Processing:  Dynamic,  event  step. 

Treatment  of  Randomness:  Stochastic  or  deterministic, 
depending  on  data  availability  and  «•  tudy  purpose. 

Sidedness :  One-sided. 

LIMITATIONS :  Assumes  Perfect  Communications;  Nodes  100% 

Available;  Mission  Characteristics  Not  Dynamic  (i  e.,  they  are 
input);  Represents  Only  Brigade  Slice  of  Fire  Support  Assets; 
Unlimited  Amount  of  Ammunition  Played. 

PLANNED  IMPROVEMENTS / MODIFICATIONS :  Add  division  assets,  and 
more  sensors . 

INPUT :  Force  Structure;  Cc  tmunications  Net  Structure;  Processing 

Times  (Device  and  Operator);  Fire  Reguest  File. 

OUTPUT :  Fire  Mission  Data  (detailed  data  on  fire  missions 

reguested,  those  completed,  and  those  rejected);  Fire  Unit  Data 
(hourly  summary  of  fire  unit  usage);  Net  Utilization  Data. 

HARDWARE  AND  SOFTWARE: 

Computer  (OS):  SUN  (UNIX),  Gould  (UNIX),  11/785  (VMS). 

Storage  Required:  10  Megabytes  of  Hard  Disk. 

Peripherals :  None. 

Programming  Language:  SIMSCRIPT. 

Documentation :  Draft  input  manual. 

SECURITY  CLASSIFICATION:  (Model  without  data)  UNCLASSIFIED. 

GENERAL  DATA: 

Database :  Eight  man-week?  to  develop  new  force  structure 

input . 

CPU  Time  per  Cycle:  10  to  60  minutes  for  20  hours  battle  with 
20  to  180  targets  per  hour. 

Data  Output  Analysis:  Several  weeks  depending  on  study 
complexity . 
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OATF  IMPLEKENTED:  1 1/10/89 


TITLE:  First  Battle:  Battalion  through  Corps  (FB:  B-C) 

MODEL  TYPE:  draining  and  Education 

PROPONENT:  U.S.  Army  Combined  Arms  Command  -  Training,  ATTN:  ATZL-CTS 
Ft.  Leavenworth,  KS  66027 

POINT  OF  CONTACT:  CPT  John  Hughes,  ATZL-CTS-BB,  AV  552-3189 
USACAC-Training,  Ft.  Leavenworth,  KS  66027 

PURPOSE:  FB:  B-C  trains  unit  commanders  and  staffs  in  the  control  and 
coordination  of  combined  arms  operations  in  a  simulated  combat 
environment.  Exercises  a  unit's  tactical  SOP's. 

DESCRIPTION: 

Domain:  The  model  plays  land,  air  and  sea. 

Span:  Any  irap  -  theater  to  local. 

Environment:  Played  on  standard  maps.  Plays  day /night.  Models  road 
bridges,  cities  and  obstacles. 

Force  Composition:  Any  force. 

Scope  of  Conflict:  Plays  all  weapon  systems  including  NUC/CHEM. 
Mission  Area:  Conventional  force  to  corps. 

Level  of  Detail  of  Processes  and  Entities:  Army  to  single  soldier. 
CONSTRUCTION: 

Human  Participation:  Human  participation  required  for  decisions  and 
to  process  model. 

Time  Processing:  Static. 

Treatment  of  Randomness:  Stochastic,  Monte  Carlo. 

Sxdedness:  Two-sided,  asymmetrical. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  Update  user  and  training 
documentaicn . 

INPUT:  Movement/critical  orders,  unit  names/locations,  resupply, 
scenario . 

OUTPUT:  Conflict  resolution,  Battle  Damages,  personnel  and  logistics, 
loses  and  reports. 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS) :  IBM  compatible  PC.  MS  DOS 

STORAGE:  10  megabyte  hard  disk  with  a  minimum  of  5  megabytes  free. 
PERIPHERALS:  Epson- type  printer. 

PROGRAMING  LANGUAGE:  Turbo  Pa seal 

DOCUMENTATION :  Installation  guide,  Basic  Rules  and  Supplements  for 
play . 

SECURITY  CLASSIFICATION :  UNCLASSIFIED. 

GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE:  1  day. 
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CPU  TIME  PER  CYCLE:  Unknown 
DATA  OUTPUT  ANALYSIS :  N/A 

USERS:  Commanders  and  staffs,  battalion  through  corps. 
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TITLE :  Flexible  Attrition  Model 


FAM 


DATE  IMPLEMENTED:  1988. 

MODEL  TYPE:  Analysis. 

PROPONENT :  Directorate  Science  (Air),  Ministry  of  Defence,  Main 

Building,  Whitehall,  London  SW1A  2HB. 

DEVELOPER:  Software  Sciences  Limited,  Meudon  Avenue, 

Farnborough,  Hampshire,  GUI  4  7NB . 

POINT  OF  CONTACT:  Assistant  Director  Sc2  (Air) .  Military  - 
87068MB,  Civilian  -  071-21-87068. 

PURPOSE :  Mission  level  research,  evaluation  and  operational 

support  tool,  simulating  the  land/air  battle,  specifically  the 
interaction  between  airborne  defensive  systems  and  ground  based 
Air  Defence  systems;  with  applications  for  both  airborne  and 
ground  based  weapon  system  effectiveness,  force  requirement  and 
mix,  deployment,  concept  evaluation  and  decision  making 
evaluation . 

DESCRIPTION: 

Domain :  Land/air. 

Span :  Global,  accommodates  any  theatre  for  which  a  ground  data 

base  exists. 

Environment :  Models  terrain  and  cultural  features. 

Force  Composition:  Blue  on  Red/Red  on  Blue. 

Scope  of  Conflict:  Conventional  or  Nuclear  environment; 
Airborne  defensive  systems  -  ECM,  RWR,  IR  flares,  Chaff,  anti¬ 
radiation  missile;  Ground-based  Air  Defence  systems  - 
Surveillance,  acquisition  and  tracking  sensors  and  associated 
weapon  systems,  SAM,  gun,  laser. 

Mission  Area:  All  airborne  missions  including  stand-off 
activity  and  penetration  by  manned  aircraft,  UAV  or  missile. 

Level  of  Detail  of  Processing  and  Entities: 

Processes :  Attrition/survivability  of  airborne  platforms, 

effects  of  C3I  of  Ground  Based  Air  Defence  systems,  defence 
suppression,  effects  of  stealth  on  platform  survivability. 

Entities :  64  air  vehicles  against  100  ground  sites,  large 

aircraft  formations  down  to  single  defensive  system  on 
singleton  aircraft,  multiple  networked  ground  sites  down  to 
single  autonomous  site.  Attrition/survivability  for  aircraft 
are,  probability  of  kill,  Monte  Carlo  based,  stochastic,  output 
for  ac/system  by  type,  group  or  formation. 
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CONSTRUCTION: 

Human  Participation:  Not  required.  Not  permitted  after  the 
initial  set-up  (Scenario  Generation)  phase. 

Time  Processing:  Dynamic,  event  based  model,  with  some 
activities  time-stepped. 

Treatment  of  Randomness:  Air  attrition  stochastically  based  on 
computation  of  probability  of  detection,  engagement  and 
probability  of  kill,  with  Monte  Carlo  determination  of  results. 

Sidedness :  Two-sided  with  symmetric  modelling  of  the  activity 

within  both  air  and  ground  environments. 

LIMITATIONS :  Does  not  model  air-to-air  engagements. 

PLANNED  IMPROVEMENTS /MODIFICATIONS :  Model  is  constantly  being 
developed  under  Ministry  of  Defence  contract.  Current 
development  includes  improvement  to  aircraft  reactive  manoeuvre, 
C3I,  EW  and  missile  guidance  modules. 

INPUT :  Graphical  scenario  definition  package. 

OUTPUT :  Graphics  analysis  package. 

HARDWARE  AND  SOFTWARE: 

Computer :  Designed  to  run  on  PRIME  computer,  VAX  computer  and 

SUN  workstation,  but  model  is  fully  transportable. 

Storage :  22  megabytes  (for  executable  version). 

Peripherals :  Minimum  requirements:  Sun  sparcstation  I. 

Programming  Language:  FORTRAN  77. 

Documentation :  Extensively  documented  at  four  levels  from  high 

level  functional  overview  down  to  code. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED,  but  individual  modules 
are  classified  up  to  SECRET. 

GENERAL  DATA: 

Data  Base:  Example  modules  are  available. 

CPU  Time  per  Cycle:  Small  scenarios  completed  in  several 
minutes . 

Data  Output  Analysis:  Results  available  in  both  hard  copy  and 
graphical  format. 


Freguency  of  Use:  Continuous  studies  and  development. 


Users :  Currently  in  use  with  Directorate  of  Science  (Air) 

Ministry  of  Defence;  Atomic  Weapons  Establishment;  Operational 
Research  Branch  Headquarters  Royal  Air  For  Strike  Command; 

Systems  Assessment  Department,  Royal  Aerospace  Establishment 
Farnborough;  Defence  Operational  Analysis  Organization  (Germany). 

Comments :  Currently  investigating  methods  of  inputing  EW  data 

from  Electronic  Warfare  Combat  Evaluation  System  (ECMES)  computer 
simulation  evaluation  tool  in  use  with  MOD.  Configuration 
control  management  exercised  through  the  FAM  Users  and 
Development  Group  (MOD). 
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TITLE :  Force  Analysis  Simulation  of  Theater  Administrative  and 

Logistics  Support  -  FASTALS  Model 

DATE  IMPLEMENTED:  1971. 

MODEL  TYPE:  Analytical. 

PROPONENT:  U.S.  Army  Concepts  Analysis  Agency,  Attn:  Force 

Directorate,  8120  Woodmont  Avenue,  Bet  ^sda,  MD  20814-2797. 

POINT  OF  CONTACT:  Mr.  Raymond  G.  McDowall,  (AV)  295-1658. 

PURPOSE :  The  objective  of  FASTALS  is  to  develop  the  balanced, 

time-phased  support  force  requirements  for  a  specified  combat 
force.  FASTALS  is  used  primarily  for  force  planning  studies  and 
analysis  generally  in  the  context  of  the  Defense  Guidance 
Illustrative  Planning  Scenario  (DGIPS). 

DESCRIPTION: 

Domain:  Land. 

Span :  Each  run  accommodates  one  theater  with  a  specified 

combat  force  in  a  combat  scenario. 

Environment :  Theater  dependent. 

Force  Composition:  Specified  by  study  sponsor  and  used  to 
generate  requirements  for  Army  logistical  units. 

Scope  of  Conflict:  N/a. 

Mission  Area:  FASTALS  is  a  deterministic  computer  program  that 
was  developed  to  generate  the  time-phased  Army  support 
requirements  that  result  from  a  given  combat  simulation. 

Level  of  Detail  of  Processes  and  Entities:  Support 
requirements  are  generated  for  each  unit  type  (functional  area) 
including  engineer,  chemical,  medical,  transportation,  ordnance, 
quartermaster,  et  al,  by  Standard  Requirements  Code  (SRC).  The 
workload  requirements  needed  to  sustain  the  forces  are  also 
generated  and  displayed  workloads  include  maintenance, 
construction,  supply  consumption,  transportation,  patient  care, 
personnel  replacement,  and  other. 

CONSTRUCTION: 

Human  Participation:  All  inputs  are  developed  by  functional 
area  analysts  prior  to  model  execution.  No  interaction  is 
permitted  during  model  execution. 

Time  Processing:  Dynamic  time-step. 
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Treatment  of  Randomness:  Determination. 


Sidedness :  One-sided. 

LIMITATIONS :  No  attrition  to  support  units  or  retrograde 

movement  operations;  single  movement  of  units  and  supplies  from 
point  of  arrival  to  destination. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Continue  to  develop 
routines  to  facilitate  and  enhance  data  entry  and  retrieval. 

INPUT:  The  following  data  base  in  magnetic  tape  form  and  used. 

Military  Traffic  Management  Command  weights  file,  Army  MARC 
Maintenance  Data  Base,  Force  Accounting  System  unit  data,  and 
Consumption  factor  data  (provided  on  floppy  disks)  from  the  U.S. 
Army  Logistics  Center. 

OUTPUT :  Force  listing  is  in  the  form  of  a  time-phased  troop  list 

indicating  unit  requirements  by  SRC. 

HARDWARE  AND  SOFTWARE: 

Computer:  UNISYS  1100/84. 

Storage :  1 . 5  Mb . 

Peripherals :  Two  9-tract,  6250-byte-per-inch  tape  drives. 

Language :  FORTRAN- 7  7 . 

Documentation :  User's  Manual  and  Programmer's  Guide. 

GENERAL  DATA: 

Data  Base:  One  man-month  or  more  depending  on  size  of  force 
and  complexity  of  theater  being  evaluated. 

CPU  Time  Per  Cycle:  Thirty  minutes. 

Data  Output  Analysis:  Two  weeks  or  more  depending  upon 
theater . 

Freguencv  of  Use:  Used  approximately  30  times  per  year  for 
record  runs . 

Users :  USACAA,  U.S.  Army  Logistics  Center,  U.S.  Army  Logistics 

Evaluation  Agency. 

Comments :  This  mode  has  been  used  for  20  years  to  develop  the 

support  force  requirements  for  the  Army  and  is  accepted  as  the 
standard  by  which  other  models  are  measured. 
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TITLE :  Force  Evaluation  Model 


FORCEM 


DATE  IMPLEMENTED:  1985. 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.S.  Army  Concepts  Analysis  Agency,  8120  Woodmont 

Avenue,  Belhesda,  MD  20814-2797. 

POINT  OF  CONTACT:  Dr.  R.  Johnson,  (AV)  295-1593/(301)  295-1593. 

PURPOSE :  The  model  provides  simulation  of  airland  activities  in 

a  theater  of  operations  over  an  extended  period  (up  to  90  days). 
Combat  operations  are  at  the  division  level  and  most  of  the 
combat  support  and  combat  service  support  functions  from  the  port 
to  FLOT  are  represented.  It  is  a  fully  computerized  simulation 
for  application  in  studies  and  analyses  of  force  planning  and 
resource  allocation  issues.  The  model  is  part  of  a  three  level 
hierarchy  of  Army  simulation  models  (at  Battalion,  Division/Corps 
and  Theater)  developed  under  the  Army  Model  Improvement  Program. 

DESCRIPTION: 

Domain :  Land  -  air. 

Span:  Theater  campaign.  Current  data  bases  are  Central 

Europe,  and  Southwest  Asia. 

Environment :  Terrain  square  of  selectable  size  (5-30km). 

Eight  terrain  types,  including  urban  and  water  areas,  affecting 
movement.  Day  and  night  difference  for  some  operations.  No 
weather.  Road,  rail  and  water  transport  represented  as  networks. 

Force  Composition:  Joint  and  combined  forces.  Blue  and  Red. 
Blue  force  partitioned  into  two  components  for  resource 
accounting  purposes. 

Scope  of  Conflict:  Primarily  conventional.  Chemical  module 
operational  and  nuclear  module  under  development. 

Mission  Area:  Theater  ground  operations  with  fire  support 
(including  air)  and  combat  service  support,  including  medical, 
maintenance,  supply,  and  transportation  functions. 

Level  of  Detail  of  Processes  and  Entities:  The  level  of 
resolution  of  combat  units  is  the  division.  Combat  support  and 
combat  service  support  operations  are  represented  by  smaller 
organizational  elements,  or  as  aggregates  of  smaller  units  (e.g. 
a  single  support  command  at  each  echelon  representing  all  combat 
service  support  activities).  Functional  submodels  represent  the 
major  activities  of  target  acquisition,  communications,  command 
and  control,  division  engagement,  fire  support,  air  operations, 
unit  movement  and  combat  service  support.  As  an  average  value 
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simulation,  without  player  interaction,  command  and  control  is 
represented  by  automated  decision  processes  at  three  levels  in 
the  theater  (Corps,  Army  Group,  Theater).  Assessment  of  division 
battle  is  made  through  an  analytic  representation  of  a  division 
engagement  with  sets  of  attrition  coefficients  calibrated  to  the 
results  of  engagements  simulated  by  an  independent  division 
model.  Air  operations  are  represented  by  groups  of  aircraft,  by 
mission  (eight  possible),  in  an  air  sector  (roughly  Corp  or  Army) 
or,  in  a  few  cases,  theater-wide.  Area  air  defense  is  considered 
at  the  same  air  sector  level. 

CONSTRUCTION: 

Human  Participation:  Model  is  interruptable,  mostly  for 
purposes  of  command  and  control  to  change  unit  boundaries  and 
phase  lines  or  air  role  apportionment  factors.  Scheduled  changes 
also  allowed. 

Time  Processing:  Dynamic,  time  step  model  with  twelve  hour 
time  cycle. 

Treatment  of  Randomness :  Deterministic,  without  randomness  in 
the  model.  Some  inputs  are  expected  values  generated  from 
stochastic  processes. 

Sidedness :  Two  sided,  generally  symmetric.  Command  and 

control  input  data  may  be  varied  by  national  component  on  each 
side  to  represent  different  decision  factors. 

LIMITATIONS :  No  naval  operations,  weather,  engineer  functions, 

EW  or  rear  area  combat.  Highly  aggregated  intelligence  and 
communications . 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Presently  revising 
command  and  control  and  engagement  process  for  asymmetric 
representation  of  Blue  and  Red  operations  and  for  better 
representation  of  breakthrough  and  reserve  and  second  echelon 
force  employment.  Upgrades  to  intelligence/target  acquisition 
and  nuclear/chemical  representation  and  addition  of  engineer 
functions  planned. 

INPUT: 

•  In-theater  force-units  and  their  assets 

•  Arrival  schedule-units  and  assets 

•  Theater  scenario  and  plans 

•  Terrain 

•  Engagement  results  from  division  level  simulation 

•  Weapons  and  equipment  characteristics 

•  C2  decision  criteria 

•  Performance  factors  for  surveillance,  communications, 
repair,  medical,  transport,  etc.,  functions 
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OUTPUT: 


•  Computer  reports,  giving  status,  losses,  and  expenditures  of 
units  and  assets  over  time 

•  Computer  graphics  graphs  and  map  displays 

•  Hard  copy  plots  and  charts 

HARDWARE  AND  SOFTWARE: 

Computer :  UNISYS  1100/84,  SUN  4/260. 

Storage :  One  to  three  million  decimal  words,  depending  on 

scenario . 

Peripherals :  Disk  storage,  demand  CRT  terminal,  computer 

graphics  terminal  and  plotter  for  input  and  output  preparation, 
tape  unit  for  checkpoint/restart  capability. 

Programming  Language:  SIMSCRIPT  II. 5. 

Documentation :  FORCEM  Input  Data,  October  1990;  FORCEM  Output 

Reports,  May  1989.  Formal  documentation  not  yet  published. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED,  without  data. 

GENERAL  DATA: 

Data  Base:  Three  to  six  months  required  to  build  new  data  base 
from  scratch. 

CPU  Time  Per  Cycle:  Depends  on  scenario.  Average  of  15-20 
minutes  per  twelve  hour  cycle. 

Data  Output  Analysis:  Highly  variable,  depending  on  study. 
Large  volume  of  output  is  reduced,  combined  and  manipulated  by  a 
post  processor  information  retrieval  system  (UNISYS  MAPPER). 

Freguencv  of  Use:  Four  per  year  for  major  studies. 

Users :  Used  only  at  the  U.S.  Army  Concepts  Analysis  Agency. 

Comments :  Model  operates  in  hierarchial  mode  and  is  dependent 
on  results  from  higher  resolution  division  model  (presently 
COSAGE)  for  combat  attrition  and  munition  expenditures. 
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TITLE :  General  Full  Spray  Materiel/Personnel  Mean  Area  of 

Effectiveness  -  MAE  (AKA  Lethal  Area  Program) 

DATE  IMPLEMENTED:  1979  ( JTCGME  Version). 

MODEL  TYPE;  Analysis. 

PROPONENT :  U.  S.  Army  materiel  Systems  Analysis  Activity,  Ground 

Warfare  Division,  Support  Warfare  Analysis  Branch,  Aberdeen 
Proving  Ground,  MD  21005-5071. 

POINT  OF  CONTACT:  Russell  Dibelka,  DSN  298-5046/(301)  278-5046. 

PURPOSE :  The  Lethal  Area  Program  is  used  to  analyze  item  level 

performance  by  computing  the  effectiveness  of  one  conventional 
weapon  against  one  materiel  or  personnel  target. 

DESCRIPTION: 

Domain :  Surface-to-surface,  air- to-surface . 

Span :  Individual  (Item). 

Environment :  Open  environment  is  the  default  condition.  The 

environmental  shielding  of  the  target  option  allows  a  choice  of 
tropical  forest,  temperate  forest,  jungle  tangle,  and  coniferous 
forest.  Another  option  allows  the  effect  of  tall  grasses  on 
projectile  drag  to  be  evaluated.  Personnel  targets  are  assessed 
in  four  postures:  standing,  prone  protected,  and  crouching  in  a 
foxhole . 

Force  Composition:  One-on-one,  Red  and  Blue. 

Scope  of  Conflict:  Indirect  fire  weapons  such  as  unitary 
warheads,  submunitions,  flechettes,  mortars,  bombs,  laser-guided 
munitions,  and  terminally-guided  munitions. 

Mission  Area:  Fire  Support  and  Close  Combat  Light  (mortars 
only )  . 

Level  of  Detail  of  Processing  and  Entities:  The  only  entity 
modelled  is  an  individual  weapon  versus  an  individual  target.  No 
processes  such  as  attrition,  communications,  and  movement  are 
modelled . 

CONSTRUCTION: 

Human  Participation:  None  required  not  permitted. 

Time  Processing:  Static. 

Treatment  of  Randomness:  Stochastic  model  with  direct 
computation . 
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Sidedness :  One-sided. 


LIMITATIONS :  The  effects  of  blast  on  the  target  and  a  direct  hit 

on  the  target  cannot  be  modelled  simultaneously.  Multiple 
critical  components  (i.e.,  site  kills)  cannot  be  modelled. 

Lethal  area  is  calculated  for  only  one  submunition  (bomblet),  not 
the  entire  payload. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Link  input  and  output 
dir  directly  to  Fire  Support  database. 

INPUT:  Weapon  characteristics  and  fragmentation  data,  target 

vulnerability  data. 

OUTPUT :  Computer  printouts  containing  input  data  and  lethal 

areas.  Options  permit  calculation  and  printouts  of  other 
measures  of  effectiveness  { PKs ,  CEP's,  etc). 

HARDWARE  AND  SOFTWARE: 

Computer  (OS):  Alliant  computer  UNIX-type  operating  system 
( AMSAA  Version);  Cyber  Computer  with  NOS  operating  system 
(JTCG/ME  version). 

Storage :  .36  megabyte  (FORTRAN  code  only). 

Peripherals :  Printer. 

Programming  Language:  FORTRAN  V. 

Documentation :  Joint  Technical  Coordinating  Group  for 

Munitions  Effectiveness  (JTCG/ME  manuals). 

SECURITY  CLASSIFICATION:  Model  is  UNCLASSIFIED,  however,  input 
and  output  are  usually  classified  up  to  SECRET/NOFORN. 

GENERAL  DATA: 

Data  Base:  New  fragmentation  data  (primarily  from  arena 
testing)  can  take  several  man-months  after  testing  is  completed 
to  be  made  available.  New  target  vulnerability  data  (primarily 
developed  by  the  Ballistic  Research  Laboratory)  can  take  one  man- 
year.  To  set  up  an  input  file  for  one  weapon/target  combination 
with  existing  fragmentation  and  vulnerability  data  from  the  Fire 
Support  database  takes  a  few  minutes . 

CPU  Time  Per  Cycle:  Usually  less  than  five  minutes  and 
frequently  less  than  one  minute. 

Data  Output  Analysis:  Input  data  are  printed  for  verification 
purposes.  Lethal  area  output  is  used  as  input  to  the  ARTQUIK 
model  as  well  as  several  higher  models.  However,  there  is  no 
direct  linkage  between  the  models  nor  specific  analysis  of  the 
lethal  area  output. 

Freguencv  of  Use:  Varies  with  the  number  of  studies  being 
supported,  but  probably  several  hundred  times  throughout  the 
year . 
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Users :  AMSAA,  OSU-Field  Office  (JTCG/ME  version),  DoD 

contractors,  other  DoD  agencies. 

Releasabilitv :  Military  Use  Only. 


TITLE: 


Ground  Wars 


DATE  IMPLEMENTED:  1987. 


MODEL  Tit  PS:  Analysis. 

PROPONENT :  U.  S.  Army  Materiel  Systems  Analysis  Activity, 

Attn:  AMXSY-GC,  Aberdeen  Proving  Ground,  MD  21005-5071. 

POINT  OF  CONTACT:  Thomas  Ruth,  AV  298-2924/(301)  278-2924. 

PURPOSE :  Grounawars  is  primarily  used  to  evaluate  weapon  system 

effectiveness.  The  model  can  address  ammunition  expenditures, 
acquisition,  delivery  accuracy,  vulnerability,  lethality,  rate  of 
fire,  disengagement  policies,  effect  of  line-of-sight  due  to 
terrain  or  obscurants,  and  the  effect  of  various  round  types 
(e.g.  KE,  HEAT,  command-to-line-of-sight ,  fire  and  forget,  or 
near  simultaneous-engagement  type  missiles). 

DESCRIPTION: 

Domain :  Land  combat  between  homogeneous  forces. 

Span :  Accommodates  any  regional  area  depending  on  database. 

Environment :  The  model  is  limited  to  a  total  of  20  combatants, 

including  fighting  systems  and  decoys.  methodology  incorporated 
includes  near-simultaneous  f ire-and-forget  missiles,  artillery, 
multi-target  acquisition  (attacker  groups),  line-of-sight 
enhancements  and  the  ability  for  tanks  to  jockey  during  the 
engagement  process. 

Force  Composition:  Blue  and  Red  homogeneous  ftj ;es. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  All  conventional  missions. 

Level  of  Details  of  Processes  and  Entities:  Attrition  of 
ground  systems  are  probability  of  kill,  Monte  Carlo  based,  and 
output  single  system  kills. 

CONSTRUCTION: 

Human  Participation:  None. 

Time  Processing:  Dynamic,  event  stepped  model. 

Treatment  of  Randomness:  Stochastic  employing  Monte  Carlo 
probability  theory  as  its  primary  solution  technique. 

Sidedness :  Two-sided,  symmetric  mode1. 

LIMITATIONS :  Groundwars  simulates  only  homogeneous  forces  on 

each  side.  The  total  number  of  combatants,  attacker  and  defender 
combined,  cannot  exceed  twenty. 
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PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Heterogeneous  forces  as 
well  as  multi-weapon  per  platform  are  changes  currently  planned. 

INPUT:  None. 

OUTPUT :  Enhance  output  with  the  aid  of  graphics. 

HARDWARE  AND  SOFTWARE: 

Computer:  GOULD  9080,  VAX-1  1  /780,  CRAY  X-MP,  CRAY  II,  FHX 

Alliant  or  386  PC. 

Storage :  200K. 

Peripherals :  None. 

Programming  Language:  FORTRAN  77. 

Documentation :  AMSAA  Technical  Report  478  "Groundwars  4.0 

User's  Guide",  date  October  1989. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED,  but  data  bases  are 
classif ied . 


GENERAL  DATA: 

Data  Base:  Scenario  dependent  -  approximately  two  weeks. 
Creation  of  input  files:  two  days  -  one  week.  To  analyze 
output:  one  day  -  one  week. 

CPU  Time  per  Cycle:  GOULD  9080:  20-25  minutes  per  300 
replications.  FHX  Alliant:  45  minutes  per  300  replications. 
CRAY'S:  3-5  minutes  per  300  replication. 

Data  Output  Analysis:  Produces  hard  copies. 

Freguencv  of  Use:  Continuous. 

Users :  USAMSAA,  U.  S.  Army  Missile  Command,  U.S.  Army  Armor 

School,  Kaman  Science  Corporation,  Rockwell  International,  U.  S. 
Army  Tank  Automotive  Command,  U.  S.  Natick  Research  Development 
and  Engineering  Center,  General  Dynamics  Land  System  Division  and 
Surviac  operated  by  Booz,  Allen  and  Hamilton,  Incorporation. 


TITLE :  Guided  Artillery  Munitions  Effectiveness  Simulation  II 

GAMES  II 

DATE  IMPLEMENTED:  1991. 

MODEL  TYPE :  Analysis. 

PROPONENT:  U.  S.  Army  Materiel  Command. 

POINT  OF  CONTACT:  U.  S.  Army  Materiel  Systems  Analysis  Activity, 
Attn:  AMXSY-GS  (Martin  Perry),  Aberdeen  Proving  Ground,  MD 

21005-5071,  DSN  298-5030/(301 )  278-5030. 

PURPOSE :  GAMES  II  is  a  research  and  evaluation  tool  which 

calculates  system  effectiveness  of  most  indirect  fire  artillery 
indirect  fire  smart  munition  concepts. 

DESCRIPTION: 

Domain :  Land. 

Span :  Single  scenario;  many  munitions  against  many  targets. 

Environment :  Insensitive  to  terrain,  simulates  weather 

conditions  by  changing  munition  acquisition  probabilities. 

Force  Composition:  Portrays  different  types  of  vehicles  in 
a  target  array. 

Scope  of  Conflict:  Conventional  "smart"  munitions. 

Mission  Area:  Primarily  deep  land  battle. 

Level  of  Detail  of  Processes  and  Entities:  Models  individual 
vehicles  such  as  tanks  in  a  moving  or  stationary  target  array. 

By  using  probabilities  of  detection/hi t /kill  it  calculates 
vehicle  kills. 

CONSTRUCTION: 

Human  Participation:  Not  required. 

Time  Processing:  Dynamic,  event  stepped  model. 

Treatment  of  Randomness:  Stochastic  Monte  Carlo  simulation. 


Sidedness :  One-sided. 

LIMITATIONS :  Since  model  is  event  driven,  it  can  not  consider 

the  synergistic  effects  of  multiple  volleys  spaced  in  time. 
Target  array  elements  killed  continue  simulated  movement  within 
column . 


PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  None . 

INPUT :  Target  array  description:  number  of  vehicles,  type, 

location-including  false  targets.  Target  location  errors, 
delivery  errors,  carrier/submunition  reliability.  Submunition 
characteristics:  probability  of  acquisition/hit/kill . 

OUTPUT :  Average  number  of  munition  failures.  Number  of  vehicle 

acquisitions,  hits,  kills  and  the  types  of  vehicles  they  were. 

HARDWARE  AND  SOFTWARE: 

Computer :  Digital  mainframe  or  personal  computer.  Can  run  on 

any  operating  system  with  only  changes  in  the  command  file. 
Storage :  160  Kilobytes. 

Peripherals :  Line  printer  or  monitor,  magnetic  disk  tape 

drive,  or  hard/floppy  drive. 

Programming  Language :  Standard  Fortran  77. 

Documentation :  (Draft  user  and  analyst  manual)  published  as 

draft  AMSAA  Technical  Report,  dated  July  1985. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED. 

GENERAL  DATA: 

Data  Base:  Depends  on  the  analysis  done. 

CPU  Time  per  Cycle:  Depends  on  computer  being  used. 

Data  Output  Analysis:  One  to  two  weeks. 

Freguencv  of  Use:  Continuous  at  AMSAA. 

Users :  Primarily  AMSAA,  also  used  at  Fort  Sill,  and  TRAC  WSMR, 

and  by  some  contractors . 

RELEASABILITY :  Releasability :  Approved  for  public  release; 

distribution  unlimited  for  most  versions  of  GAMES. 
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TITLE ;  Gun  Effectiveness  Model  -  GEM 


DATE  IMPLEMENTED:  1980. 


PROPONENT:  U.S.  Army  Materiel  Systems  Analysis  Activity, 

Aberdeen  Proving  Ground,  MD  21005-5071. 

POINT  OF  CONTACT:  John  Meredith,  DSN  298-6405/(301)  278-6405. 

PURPOSE :  GEM  is  a  small,  simplified  model  which  require  a 

minimum  of  inputs  and  computer  run  time,  giving  results  of 
sufficient  accuracy  for  used  in  short  turn-around  time  studies 
and  parameters  analyses.  The  model  computes  air  defense  gun 
system  effectiveness  against  single  targets. 

GENERAL  DESCRIPTION: 

Domain :  Ground  to  air. 

Span :  Individual  gun  against  single,  passive  target. 

Environment :  Featureless. 

Force  Composition:  Single  air  defense  gun,  single  aircraft 
target. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Air  defense. 

Level  of  Detail  of  Processes  and  Entities:  Computation  of  kill 
probabilities  are  made  for  a  single  burst  of  rounds  from  the  gun, 
based  on  the  number  of  rounds,  the  gun's  accuracy  and  ammunition 
dispersion,  and  the  target's  location  and  vulnerability.  The 
model  consists  of  four  parts.  These  are  (1)  the  target's  state; 
(2)  the  gun's  aiming  errors;  (3)  the  projectile  flyout  time  and 
dispersion;  and  (4)  the  aircraft's  vulnerability  to  the 
projectile.  The  projectile's  trajectory  is  computed  with  the 
"3/2  Law",  the  vulnerable  areas  are  represented  by  a  "shoebox", 
and  the  probabilities  are  computed  by  the  salvo,  or  Carlton, 
formula . 

CONSTRUCTION: 

Human  Participation:  Not  required. 

Time  Processing:  Static. 

Treatment  of  Randomness:  Generates  an  expected  value  of  the 
probability  of  hit  or  kill. 

Sidedness :  One-sided. 

LIMITATIONS :  Model  only  considers  lethality  of  a  single  burst, 

given  a  shot. 


PLANNED  IMPROVEMENTS /MODIFICATIONS :  None . 


INPUT:  Target  aircraft  location  and  velocity  at  time  of  fire  or 

at  time  of  projectile  intercept;  Target  cardinal  direction 
vulnerable  areas;  Gun  accuracy  and  ballistic  dispersion; 
Projectile  muzzle  velocity  and  drag  factor,  Number  of  rounds  per 
burst . 

OUTPUT :  Target  position  at  time  of  fire  and  a  time  of 

projectile;  Range  and  remaining  projectile  velocity  at  intercept; 
Projectile  time-of-f light ;  Apparent  vulnerable  area;  Probability 
of  hit  or  kill. 

HARDWARE  AND  SOFTWARE: 

Computer :  Any . 

Storage :  316  lines  of  FORTRAN  coding. 

Peripheral :  Input  device,  printer. 

Programming  Language:  FORTRAN,  BASIC. 

Documentation :  AMSAA  TR  337,  The  Air  Defense  Gun  Effectiveness 

Model,  September  1981,  AD  B059981L. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED. 

GENERAL  DATA: 

Data  Base:  Input  requires  13  variables. 

CPU  Time  per  Cycle:  A  few  seconds. 

Data  Output  Analysis:  Output  contains  7  values. 
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TITLE :  Helicopter  Air-to-Air  Combat  Simulation  -  HATACS 

DATE  IMPLEMENTED:  September  1978. 

MODEL  TYPE:  Analysis. 

PROPONENT:  U.S.  «imy  Materiel  Systems  Analysis  Activity, 

Attn:  AMXSY-AAG,  Aberdeen  Proving  Ground,  MD  21005-5071. 

POINT  OF  CONTACT:  Robert  Sacco,  DSN  298-6396/(301)  278-6396. 

PURPOSE:  HATACS  is  used  primarily  to  evaluate  the  effectiveness 

of  Blue  and  Red  gun  systems  (both  current  and  proposed)  against 
current  and  proposed  air-to-air  threats. 

DESCRIPTION: 

Domain:  Air-to-air. 

Span :  Local. 

Environment :  Benign. 

Force  Composition:  One  attacker  and  one  target  aircraft. 

Scope  of  Conflict:  Aircraft  Gun  systems  (up  to  40mm). 

Mission  Area:  Close  Air  Support. 

Level  of  Detail  of  Processes  and  Entities:  Calculates  the 
probability  of  Attrition,  Forced  Landing  and  Mission  Abort  Kill 
categories  and  the  probability  of  hitting  (PH)  the  target. 

CONSTRUCTION: 

Human  Participation:  Not  required. 

Time  Processing:  Static. 

Treatment  of  Randomness:  Deterministic  and  generates  a  value 
as  function  of  an  expected  value. 

Sidedness :  One-on-one  with  pseudo-dual  encounter. 

LIMITATIONS :  One-on-one,  passive  target,  no  terrain,  weather  or 

countermeasures . 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  None  at  this  time. 

INPUT :  Projectile  trajectory  characteristics,  ballistic 

dispersion,  fire  control  errors,  gun  rate-of-fire  and  target 
vulnerability . 
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OUTPUT :  Produces  printout  of  tables  with  PKs  for  the  3  levels  of 

kill  (Attrition,  Forced  Landing  and  Mission  Abort)  and  PH  as 
functions  of  Range  and  Target  Aspect  Angle. 

HARDWARE  AND  SOFTWARE: 

Computer:  Runs  on  CRAY  II  and  Alliant  computers  with  the  UNIX 

operating  system. 

Storage :  1  MB  for  executable  program. 

Peripherals :  1  printer  and  1  VT100  terminal. 

Programming  Language :  FORTRAN  7 7 . 

Documentation :  Thor  Informal  Report,  Y-95,  A  Description  of 

the  HATACS  Computer  Model,  P.H.  Beavers,  Thor  Group,  Falcon 
Research  &  Development  Company  for  AWD,  AMSAA,  28  September  1978. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED,  but  data  can  be 
classified. 

GENERAL  DATA: 

Data  Base:  Time  needed  to  create  one  complete  weapon-target 
combination  is  4  hours. 

CPU  Time  per  Cycle:  For  a  complete  set  of  ranges,  kill 
categories,  and  target  aspects  25  minutes  on  CRAY  II  or  4  hours 
on  Alliant. 

Freguencv  of  Use:  Varies,  but  is  used  several  times  per  year 
in  all  data  request  from  Army  commands  for  item  level  performance 
data . 
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TITLE :  Helicopter  Launched  Missile  Antitank  Effectiveness 

Simulation  -  HELMATES  II 

DATE  IMPLEMENTED:  August  1990. 

MODEL  TYPE:  Analysis. 

PROPONENT:  U.S.  Army  Materiel  Systems  Analysis  Activity, 

Aberdeen  Proving  Ground,  MD  21005-5071. 

POINT  OF  CONTACT:  William  Smith,  AV  298-6392/(301)  278-6392. 

PURPOSE :  To  analyze  helicopter  weapon  systems  effectiveness  and 
weapon  mix  effectiveness  in  a  combat  environment. 

DESCRIPTION: 

Domain:  Air-to-ground/ground-to-air. 

Span:  Attack  helicopter  company  vs.  ground  battalion. 

Environment :  Terrain  features,  weather  and  time  of  day. 

Force  Composition:  Attack  helicopter  company  vs.  ground 
battalion. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Close  air  support. 

Level  of  Detail  of  Processes  and  Entities:  Individual  aircraft 
or  ground  vehicle  is  lowest  entity.  Processes:  attrition, 
communications,  and  movement  effects  above  entities. 

CONSTRUCTION: 

Human  Participation:  Not  required. 

Time  Processing:  Dynamic  (event  sequenced). 

Treatment  of  Randomness:  Stochastic,  both  Monte  Carlo  and 
direct  computation. 

Sidedness :  Force  on  force. 

LIMITATIONS :  Blue  aircraft  only  (attack  and  scout).  Red  threat 

limited  to  200  vehicles. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Yes,  develop  new 
scenarios . 

INPUT :  Scenarios,  weapon  characteristics,  time  lines. 


120 


OUTPUT :  Killer  victim  scoreboards,  battle  time,  average  exposure 

times,  and  kill  rates. 


HARDWARE  AND  SOFTWARE: 

Computer:  CRAY  II,  VAX. 

Peripherals :  Input  device,  printer. 

Programming  Language :  FORTRAN . 

SECURITY  CLASSIFICATION:  UNCLASSIFIED. 

GENERAL  DATA: 

Data  Base:  One  week  to  three  months. 
CPU  Time  per  Cycle:  Ten  seconds. 

Data  Output  Analysis:  One  day. 


TITLE: 


Helicopter  Operations  Model.  (HOM) 

DEVELOPER:  LA2 
USER:  LA2 

PURPOSE:  To  assess  the  effectiveness  of  a  fleet  of  Light  Support 

Helicopters  (LSH)  under  varying  conditions  and  lengths  of  battle. 

GENERAL  DESCRIPTION:  HOM  is  an  event  based  Monte  Carlo  Simulation  of  LSH 

operations  over  a  period  of  several  days.  A  sequence  of  helicopter  tasks  are 

generated,  based  on  wargames,  exercises  or  military  judgement,  and  the  ability 
of  the  specified  LSH  fleet  to  carry  out  these  tasks  is  evaluated.  The  tasks 
are  divided  into  a  number  of  categories,  which  are,  in  order  of  priority. 

a.  Immediate  operational  tasks  whose  success  depends  on 

immediate  execution. 

b.  3-hour  operational  tasks,  which  must  be  started  within  3 
hours  of  a  request  reaching  the  helicopter  unit. 

c.  Air-mobile  operations,  for  which  4  hours  notice  is  given,  and 
which  are  cancelled  if  they  cannot  start  within  3-hours  of  the 
requested  start-time. 

d.  Logistic  tasks,  which  are  only  undertaken  by  LSHs  not 

participating  in  or  committed  to  other  tasks. 

The  effectiveness  of  the  fleet  is  measured  in  terms  of  the  proportion  of  tasks 
a-c  undertaken  and  the  number  of  logistic  tasks  that  could  have  been  flown. 
The  model  takes  account  of  helicopter  numbers,  capacity  for  men  or  freight, 
loss  rates,  reliability  and  repair  times;  mission  duration,  tasking  rates  and 
battle  durations. 

COMPUTER  STATUS:  Conversion  to  VAX  intended. 

DOCUMENTATION:  DOAE  Note  145/200  dated  Nov  1984,  DOAE  Library  Acn  No  82311. 
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TITLE :  Helicopter  Piloted  Air  Combat  -  HELIPAC  Model 

DATE  IMPLEMENTED:  1989. 


MODEL  TYPE:  Analysis. 

PROPONENT :  Directorate  for  Systems  and  Cost  Analysis  (AMSAV-BA), 

U.S.  Army  Aviation  Systems  Command,  4300  Goodfellow  Blvd, 

St  Louis,  MO  63120-1798. 

POINT  OF  CONTACT:  Roger  A.  Schleper,  DSN  693-1498. 

PURPOSE :  RESEARCH  &  EVALUATION  TOOL  (SYSTEMS  EFFECTIVENESS,  MIX 

EFFECTIVENESS,  and  CURRENT  OR  NEW  DOCTRINE).  Model  assists  in 
the  evaluation  of  aircraft,  armaments,  and  tactics  by  simulating 
the  performance  of  aircraft  and  weapons  in  combat. 

DESCRIPTION: 

Domain:  Air. 

Span:  Local/individual. 

Environment :  Uses  Defense  Mapping  Agency  (DMA)  digitized 

terrain . 

Force  Composition:  Four-on-four  model,  mixed  aircraft  (fixed 
or  rotary  wing,  red  or  blue). 

Scope  of  Conflict:  Primarily  conventional  air-to-air  warfare, 
but  can  play  red  SAMs. 

Mission  Area:  All  conventional  air  combat  missions. 

Level  of  Detail  of  Processes  and  Entities:  Up  to  four 
individual  systems  on  each  side,  all  at  same  level. 

CONSTRUCTION : 

Human  Participation:  None  required  or  permitted. 

Time  Processing:  Dynamic,  using  both  time  step  and  event  step 
processing. 

Treatment  of  Randomness:  Stochastic,  using  Monte  Carlo 
techniques . 

Sidedness :  Two-sided,  asymmetric,  both  sides  reactive. 

LIMITATIONS :  Low  resolution  sensor  methodology  and  lack  of  IR 

ECM  methodology. 

PLANNED  IMPROVEMENTS /MODIFICATIONS :  Addition  of  a  turreted  gun, 
ECM  methodology,  and  the  NVEOL  model. 
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INPUT:  Engagement  scenario  data,  aircraft  descriptions,  missile 

descriptions,  firing  doctrine  and  conditions,  detection  contours, 
and  tactical  information 

OUTPUT :  Reflected  inputs,  aircraft  position  and  orientation 

versus  time,  missile  position  and  orientation  versus  time,  and 
significant  event  narrative 

HARDWARE  AND  SOFTWARE: 

Computer :  Dell  System  310,  DEC  Microvax  II,  IBM  3090-600 

Storage :  Requires  more  than  800K  bytes  of  memory  to  execute. 

Peripherals :  Printer. 

Programming  Language :  FORTRAN 

Documentation :  HELIPAC  User's  Manual  and  HELIPAC  Analyst's 

Manual,  Sikorsky  Aircraft  Division,  United  Technologies  Corp. ; 
prepared  by  Schiller  Consulting,  Chicago,  IL;  October  1990. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED. 

GENERAL  DATA: 

Data  Base:  Approximately  4  months  to  acquire  and  structure 
data  to  model  format. 

CPU  Time  per  Cycle:  1-2  minutes  per  iteration. 

Data  Output  Analysis:  Variable. 

Freguencv  of  Use:  Project  dependent. 

Users :  AVSCOM,  AMSAA,  General  Dynamics,  Sikorsky,  and  other 

SURVIAC  users. 

Comments :  Model  was  developed  by  Schiller  Consulting,  Chicago, 

IL,  and  is  an  extension  of  a  previous  model  series,  PACAM 
(Piloted  Air  Combat  Analysis  Model).  The  principal  extension  has 
been  the  inclusion  of  rotary-wing  aircraft,  with  all  of  the 
aerodynamic,  power  plant,  and  maneuver  ramifications. 

Releasabilitv :  Available  through  SURVIAC. 
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TITLE :  Helicopter  Scenario  Assessment  Model  -  HELSCAM 

DATE  IMPLEMENTED:  1989. 


MODEL  TYPE :  Analysis. 

PROPONENT :  Directorate  of  Land  Operational  Research  (DLOR), 

Operational  Research  and  Analysis  Establishment  (ORAE),  Ottawa, 
Canada  K1 A  0K2 

POINT  OF  CONTACT:  Dr.  P.J.  Young,  (613)  992-4567/AV  842-4567. 

PURPOSE :  To  analyze  the  value  of  helicopter  system  and  sub¬ 

system  characteristics  and  configurations  in  light  observation, 
light  armed,  and  attack  roles  within  realistic  "few-on-few" 
tactical  scenarios. 

DESCRIPTION: 

Domain :  Land  and  Air. 

Span :  Local.  HELSCAM  is  a  "few-on-few"  class  of  simulation. 

Environment :  On  and  over  three  dimensional  terrain  covering 

approximately  1000  square  km  in  Europe.  Designed  for  mixed 
open/forested  terrain.  Accommodates  varying  visibility  and 
weather  conditions. 

Force  Composition:  Helicopter  systems,  air  defenses,  and 
ground  combat  vehicles  of  all  major  types.  Individual  soldiers 
can  be  represented. 

Scope  of  Conflict:  Conventional  direct  fire  systems  only. 

Mission  Area:  Light  observation,  armed  reconnaissance,  and 
attack  helicopter  missions  in  contact  with  the  enemy.  Can  also 
simulate  scenarios  involving  only  conventional  direct  fire 
vehicles  and  systems. 

Level  of  Detail  of  Processes  and  Entities:  Vehicles  and  weapon 
systems  are  represented  individually.  The  engagement  sequence  of 
each  sensor /weapon  system  is  modelled  on  an  event-by-event  basis, 
including  the  processes  of  target  acquisition,  target  selection, 
target  engagement,  damage  recognition,  and  re-engagement.  Kill 
probabilities  are  drawn  from  look-up  tables.  Communication  of 
target  acquisition  and  destruction  information  between  units  on 
the  battlefield  is  represented.  Each  system  follows  a  prescribed 
path,  but  can  advance  (or  retreat)  along  that  path  at  a  rate 
determined  by  events. 


CONSTRUCTION: 


Human  Participation.  NOT  REQUIRED.  Model  is  an  automated 
simulation . 

Time  Processing:  Dynamic.  HELSCAM  is  completely  event 
stepped . 

Treatment  of  Randomness:  Stochastic.  Monte  Carlo. 

Sidedness :  Two-sided,  symmetric. 

LIMITATIONS :  Units  follow  prescribed  paths,  placing  a  practical 

upper  limit  of  approximately  30  systems  total  on  both  sides  and 
approximately  30  minutes  of  combat.  Shoot-look-shoot  engagements 
only.  Unit  information  never  incorrect,  only  incomplete. 

Digital  terrain  data  base  fidelity  limits  capability  to  play  out 
close  combat  scenarios  completely  within  forested  or  urban  areas. 
Suppression,  training,  and  morale  effects  not  modelled. 

PLANNED  IMPROVEMENTS /MODIFICATIONS :  Under  contract,  HELSCAM  is 
being  rewritten  into  C++  and  being  ported  onto  a  single  IBM/PC 
compatible  platform.  The  representation  of  ground  vehicles  will 
be  enhanced  to  the  level  of  the  helicopters  in  the  model,  at 
which  time  HELSCAM  will  be  renamed  the  Combat  Scenario  Assessment 
Model  (CCMSCAM). 

INPUT:  Terrain  data  in  two  forms:  100  meter  resolution  digital 

terrain  elevation  and  vegetation  height  data;  and  12.5  meter 
resolution  digital  terrain  classification  data.  Technical 
parameters  of  sensors,  weapons,  and  platforms,  including  PK 
tables  and  target  selection  priority  tables.  Also,  scenario 
parameters  including  unit  paths,  procedures  and  tactics. 

OUTPUT :  Event  log,  which  can  be  listed  from  a  rudimentary 

analysis  facility,  or  viewed  from  a  fully  developed  graphical 
replay  facility. 

HARDWARE  AND  SOFTWARE: 

Computer ( OS ) :  HELSCAM  simulation  core  and  analysis  facility 
runs  on  a  VAX/VMS  system.  Route  planning  and  graphical  replay 
facilities  run  on  an  IBM  PC/AT  clone  with  the  Verticom  M-256E 
graphics  card.  Eventually,  the  core  and  all  utilities  will  run 
on  a  standard  VGA-enhanced  IBM  PC. 

Storage :  Simulation  core  uses  3  MB  of  memory.  12  MB  of  disk 

space  is  desirable  to  accommodate  terrain,  input  and  multiple 
output  files. 

Peripherals :  Printer,  Verticom  monitor,  Microsoft  mouse. 

Programming  Language:  Simulation  core  in  VAX  FORTRAN. 

Graphical  Replay  and  Route  Planning  facilities  written  in 
Microsoft  C  and  Assembler. 

Documentation :  ORAE  Project  Reports  PR488,  PR489.  DLOR  Staff 

Notes  89/5,  89/6,  89/8,  89/9,  89/10,  89/11,  and  89/12. 


SECURITY  CLASSIFICATION:  Unclassified. 

GENERAL  DATA: 

Data  Base:  Several  person-weeks  to  enhance  existing  data  base 
and  develop  scenario  inputs.  Several  person  months  to  populate  a 
data  base  from  scratch. 

CPU  Time  per  Cycle:  Approximately  5  minutes  of  CPU  time  on  a 
VAX  11/751  to  simulate  30  minutes  of  combat  for  8  units. 

Data  Output  Analysis:  Variable,  from  several  hours  to  several 
days . 

Frequency  of  Use:  Applied  periodically  (several  times 
annually)  in  helicopter  or  direct  fire  studies. 

Users :  ORAE/DLOR  staff  in  support  of  Army  study  sponsors. 

Comments :  JANUS,  TAM,  and  HELSCAM  are  the  primary  combat 

models  employed  in  ORAE/DLOR  operational  research  studies. 
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TITLE :  High  Energy  Laser  Weapon  Simulation  -  HELAWS 

DATE  IMPLEMENTED:  July  1981. 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.S.  Army  Materiel  Systems  Analysis  Activity. 

POINT  OF  CONTACT:  Director,  USAMSAA,  ATTN:  AMXSY-CS 
(Mr.  Brad  Bradley),  Aberdeen  Proving  Ground,  MD  21005-5071, 

AV  298-6231 /Comm  301-278-6231. 

PURPOSE :  A  research  and  evaluation  tool  used  during  system 

development.  This  program  models  the  propagation  of  a 
high-energy  pulse  as  it  travels  through  a  turbulent  atmosphere 
and  impinges  on  a  target  sensor.  It  is  used  to  evaluate  various 
types  of  high  energy  lasers  in  an  anti-sensor  role.  The  primary 
measure  of  effectiveness  provided  by  the  model  is  probability  of 
optical  or  electro-optical  sensor  damage  as  a  function  of  range 
and  engagement  time.  Sensor  damage  includes  surface  fogging 
and/or  crazing  of  glass  or  plastic  by  carbon-dioxide  lasers 
(C02),  bulk  cracking  of  glass  by  deuteriumfloride  (DF)  lasers,  or 
Forward  Looking  Infrared  ( FLIR)  device  damage  by  C02  lasers. 

DESCRIPTION :  HELAWS  is  a  digital,  one-on-one,  simulation  of  a 

high-energy  laser  in  an  anti-sensor  role. 

Domain:  Land,  sea,  air. 

Span :  Individual  component. 

Environment :  Atmospheric  effects. 

Force  Composition:  Element. 

Scope  of  Conflict:  Any  involving  electro-optics;  item  level. 

Mission  Area:  Direct  fire  ground-ground,  ground-air,  air- 
ground  . 

Level  of  Detail  of  Processes  and  Entities: 

Entity :  Item. 

Processes :  Sensor  damage. 

CONSTRUCTION: 

Human  Participation:  Not  permitted. 

Time  Processing:  Static. 

Treatment  of  Randomness:  Stocaastic ,  Monte  Carlo. 

Sidedness :  One-sided. 
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LIMITATIONS :  Focused  beams  only;  C02  and  DF  lasers  only. 

INPUT:  Laser  Weapon  Characteristics;  Target  Sensor 

Characteristics;  Atmospheric/Meteorological  conditions; 
Engagement  parameters. 

OUTPUT :  Detailed  echo  of  input  data;  a  pulse  fluence/spot  size 

table;  pulse-by-pulse  and  multiple-pulse  damage  probability 
tables . 

HARDWARE  AND  SOFTWARE: 

Computer  (OS):  CRAY-2  (UNIX). 

Storage  required:  66K. 

Peripherals :  None . 

Programming  Language:  FORTRAN  IV. 

Documentation :  Draft. 

SECURITY  CLASSIFICATION:  (Model  without  data)  UNCLASSIFIED. 
GENERAL  DATA: 

Database :  Several  man-weeks  to  acquire  data  base;  less  than 

one  hour  to  structure  data  in  model  input  form. 

CPU  Time  per  Cycle:  1-2  seconds  per  engagement. 

Data  Output  Analysis:  Few  minutes. 
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TITLE:  Human  Engineering  Laboratory  Counterair  Program  -  HELCAP 

DATE  IMPLEMENTED:  In-process. 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.  S.  Army  Laboratory  Command,  Human  Engineering 

Laboratory . 

POINT  OF  CONTACT:  Gordon  Herald,  DSN  298-5897/(301)  278-5837. 

PURPOSE :  This  is  an  air  battle  simulation  that  deals  with  the 

development  of  soldier-machine  interfaces  in  count?  air  command 
and  control  systems. 

The  HELCAP  simulation  has  four  nodes  that  are  driven  by  a  30- 
minute  air  track  and  message  traffic  scenario.  The  nodes 
simulated  are:  1)  an  air  defense  battalion  tactical  operations 
center,  2)  an  automated  aviation  battalion  tactical  operations 
center,  3)  a  Pedestal-mounted  Stinger  air  defense  node,  and  4) 
a  generic  helicopter  simulator  node. 

DESCRIPTION: 

Domain:  Land,  air. 

Span :  Regional. 

Environment :  Terrain  cultural  features  including  tactical 
forces . 

Force  Composition:  Combined  Army  aviation  and  air  defense 
forces . 

Scope  of  Conflict:  Conventional  Red  and  Blue  weapon  systems. 
Mission  Area:  Aviation  and  air  defense. 

Level  of  Detail  of  Processes  and  Entities:  Lowest  entities 
modeled  are  the  fire  units,  individual  helicopter,  aviation 
TOC's,  and  air  defense  TOC's. 

CONSTRUCTION: 

Human  Participation:  Required  for  participation  for  decisions 
and  processes . 

Time  Processing:  Dynamic  real-time. 

Treatment  of  Randomness:  Basically  deterministic. 


Sidedness :  One-sided. 

LIMITATIONS :  The  geographic  area  is  limited  to  a  division  area 

setting  of  the  simulation. 
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PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  The  simulation  will  be 
on  line  in  July  1991.  Improvements,  as  required,  are  anticipated 
as  a  result  of  experimental  experience. 

INPUT :  Scenario  to  include  hostile  and  friendly  forces  and 

message  traffic. 

OUTPUT :  Data  related  to  soldier  performance  at  each  node. 

HARDWARE  AND  SOFTWARE: 

Computer  ( OS ) :  VAX  6410 (VMS),  Silicon  Graphics  4D/85GT(UNIX) . 
Storage :  512MB. 

Peripherals :  Graphics  systems,  printers,  sensors,  keyboards. 

Programming  Language:  FORTRAN,  C. 

Documentation :  HELCAP  Design  Guide. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED. 

GENERAL  DATA: 

Data  Base:  None. 

CPU  Time  per  Cycle:  .033  seconds. 

Data  Output  Analysis:  Post  processing. 

Frequency  of  Use:  Several  times  per  year. 

Users :  Human  Engineering  Laboratory. 
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TITLE:  HELICCS  -  Hunting  Engineering  Limited  Infantry  Close 

Combat  Simulation 

DEVELOPER:  FS  and  Hunting  Engineering  Ltd  (HEL) 

USER:  FS 

PURPOSE:  To  represent  infantry  close  combat  in  all  aspects  that  have  been 
identified  in  field  trials  and  historical  analysis  as  influencing  battle 
outcomes . 

The  model  can  be  used  to: 

a.  Simulate  infantry  battles  in  studies  involving  infantry  operations. 

b.  Generate  inputs  to  higher  force  level  models. 

c.  Assist  in  planning  field  trials  (using  weapon  simulators). 

d.  Assist  in  reconstruction  of  field  trials. 

GENERAL  DESCRIPTION:  HELICCS  is  a  stochastic  event  based  simulation  of  the 

closing  phase  of  infantry  close  combat  in  rural  terrain.  Battles  can  be 
represented  between  infantry  of  up  to  a  company  in  attack,  and  a  platoon  in 
defence  with,  if  required,  armour  and  artillery  supporting  the  attack  and 
anti-armour  weapons  and  artillery  supporting  the  defence.  The  model  simulates 
the  movements  and  engagements  by  individual  men  and  vehicles  in  rural 
environments  varying  from  open,  through  mixed  open  and  close  to  wooded  or 
forested  terrain,  and  can  take  account  of  the  degradation  due  to  the  presence 
of  live-fire  and  of  suppression  by  direct  and  indirect  fire.  The  model  has 
been  calibrated  against  the  results  of  field  trials  and  historical  analysis 
and  validated  against  historical  battles. 

COMPUTER  STATUS:  Available  on  VAX. 

DOCUMENTATION :  HEL  User  and  Program  Guides  for  HELICCS  -  DOAE  Library 

Accession  No  90785. 

COMMENT :  A  simplified  and  faster  running  model  based  partly  on  HELICCS 

outputs  has  been  produced  called  SMICC. 
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TITLE : 


DEVELOPER: 


HELSBELLS  90  -  Hunting  Engineering  Limited's  Stochastic 
Battle  Engagement  Low  Level  Simulation 

FS  and  Hunting  Engineering  Ltd  (HEL) 


USER: 


FS 


PURPOSE:  To  represent  armour  anti-armour  combat  in  all  aspects  that  have  been 
identified  by  field  trials,  and  in  particular  to  incorporate  assessments  of 
the  effects  of  thermal  imaging  (TI)  on  the  armoured  battle. 


The  model  can  be  used  to: 


a.  Simulate  armour  and  anti-armour  combat  in  attack  and  defence,  vith 
weapons  using  visual  or  visual  and  TI  sights. 

b.  Evaluate  the  effect  of  TI  and  thermal  camouflage  on  the  armoured 
battle. 


c.  Generate  input  to  higher  force  level  models. 

d.  Assist  in  planning  field  trials. 

GENERAL  DESCRIPTION:  HELSBELLS  90  (a  development  of  HELSBELLS  vith  extra 

capability  and  for  use  on  VAX)  is  a  stochastic  event  based  simulation  of 
armoured  attack  on  an  anti-armou*.  defence.  Battles  can  be  represented  between 
attacks  of  up  to  battalion  level  and  defence  of  up  to  company  level.  Tanks. 
ATGV  and  LAV  can  be  represented.  The  model  simulates  the  engagement  of 
individual  vehicles  and  weapons  moving  with  defined  rules  (rapid  approach  or 
fire  and  movement)  on  defined  routes.  Intervisibility  can  be  input  by  a 
sub-routine  using  a  terrain  model  or  from  trials  data.  The  model  has  been 
calibrated  against  the  results  of  the  DRAGONS  EYE  and  CHINESE  EYE  trials. 

COMPUTER  STATUS:  Available  on  VAX. 

DOCUMENTATION :  HEL  User  and  Program  Guides  for  HELICCS  available  from  FS. 

COMMENT:  When  historical  analysis  allows,  the  model  will  be  extended  and 

calibrated  against  historical  data. 


133 


TITLE:  IDAHEX 


DATE  IMPLEMENTED: 


MODEL  TYPE:  Analysis.  (Is  used  as  a  training  model  at  Staff  College  with  Air 
game  TAWS). 

PROPONENT :  Nov  maintained  by  users  (or  contractor).  Formerly,  IDA  or  STC. 

PURPOSE:  IDAHEX  is  a  computer  assisted  Vargame  used  to  examine  strategy  and 

tactics  at  Corps  level.  To  achieve  this  flanking  Corps  are  played.  The  level 
can  be  adjusted  upvards  to  theatre,  or  reduced  but  assumptions  rely  on 
unit: terrain  cell  relationships. 

(It  is  used  at  Camberley  to  give  command  decision  experience  and  is  played  at 
the  Theatre  level). 

DESCRIPTION 


Domain:  Land  vith  air  effects. 

Span:  Can  accommodate  any  land.  Currently  Central  Europe. 

Environment:  Based  on  hexagons  categorised  on  an  open-difficult  scale  vith 
traf ficability  and  barriers  represented  at  hex-faces.  Day  and  night  are 
modelled. 

Force  Composition:  Mixed  ground  Units,  Artillery  and  Aircraft. 

Scope  of  Conflict:  Primarily  conventional  and  chemical. 

Mission  Area:  All  conventional  warfare  but  limited  air  operations. 

Level  of  Detail:  Usually  Blue  Battlegroups  versus  Red  Regiments.  Model 
assumes  contact  battles  occur  completely  within  a  hexagonal  grid  cell.  Ground 
attrition  is  calculated  from  extended  Lanchester's  equations.  Players  obtain 
some  intelligence  reports,  give  orders  to  manoeuvre  and  combat  units  and 
assign  air  support.  Results  are  by  vehicles  killed,  ground  taken. 

CONSTRUCTION 


Human  Participation:  Required  for  decisions,  command  and  control. 

Time  Processing:  Dynamic,  time  and  event  stepping.  Cycles  are  played  of  a 
fixed  length,  typically  in  the  range  1-3  hours. 


Treatment  of  Randomness: 
hex  penetration. 


Deterministic.  Some  stochastic  representation  of 


Sidedness:  Two  sided,  can  be  played  by  2  or  more  players  and  a  game  control 

cell.  Can  be  played  open  or  closed. 

Limi tations :  Limited  air  and  logistics.  Difficult  to  represent  all  forms  of 

intelligence. 

Planned  Improvements:  To  obtain  IDAHEX  (in  its  analytical  role)  integrated 
with  an  Airgame,  TAWS.  Alternatively  to  integrate  IDAHEX  with  CAMAO. 

Input :  Terrain  categories,  attrition  coefficients,  unit  composition,  movement 

rates.  Orders  and  Air  sortie  requests. 

Output:  Attrition  tables,  intelligence  reports.  At  Corps  plus  flanking  Corps 

level  graphics. 

HARDWARE  AND  SOFTWARE 


Computer:  VAX  running  VMS 

Storage:  Playing  2.5  Corps.  Approx  4000  blocks  of  Executable  code,  situation 

save  files  at  cycles,  7000  blocks  Results  500  each. 

Graphics  additional:  Peripherals  Min  2  x  V220  terminals,  1  priner  (Sigmex 
terminal  for  graphics) 

Programming  Language:  FORTRAN 

Documentation:  Currently  being  written  for  Staff  College. 

SECURITY  CLASSIFICATION:  Code  unclassified,  some  databases  classified. 

GENERAL  DATA 


General  Data:  Data  bases  take  time  to  assemble.  Lover  level  combat  modelling 
required  to  define  attrition  data. 

CPU  Time  Per  Cycle:  Minimal,  however,  varying  gaps  between  cycles  while 

players  decide  orders  unless  a  time  limit  is  imposed. 

Data  Output  Analysis:  Limited  analytical  use  of  numeric  output.  Exploratory 
tool. 

Frequency  of  Use:  Several  times  per  year. 

Users:  D0AE  (Staff  College). 
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TITLE:  Improved  Fire  Control  Simulation  -  FIRCON 

DATE  IMPLEMENTED:  February  1990. 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.  S.  Army  Materiel  Systems  Analysis  Activity, 

Attn:  AMXSY-AAG,  Aberdeen  Proving  Ground,  MD  21005-5071. 

POINT  OF  CONTACT:  William  Nicholson,  DSN  298-6403/ ( 301 ) 278- 6403 . 

PURPOSE :  FIRCON  is  used  primarily  to  evaluate  the  effectiveness 

of  the  Apache  and  Cobra  aircraft  vs.  Red  gun  systems  (both 
current  and  proposed)  against  current  and  proposed  air-to-air 
threats . 

DESCRIPTION: 

Domain :  Air-to-air. 

Span:  Local. 

Environment :  Geographically  based  terrain. 

Force  Composition:  One  attacker  and  one  target  aircraft. 

Scope  of  Conflict:  Attacker  aircraft  gun,  rocket,  and  missile 
systems;  target  aircraft  gun  system  only. 

Mission  Area:  Close  air  support. 

Level  of  Detail  of  Processes  and  Entities:  Calculates  the 
probability  of  surviving  the  engagement  at  given  time  intervals. 

CONSTRUCTION : 

Human  Participation:  Not  required. 

Time  Processing:  Static. 

Treatment  of  Randomness:  Deterministic  and  generates  a  value 
as  function  of  an  expected  value. 

Sidedness :  One-on-one  with  pseudo-dual  encounter. 

LIMITATIONS :  One-on-one,  target  aircraft  is  limited  to  gun 
system  only;  terrain  is  an  option. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  None  at  this  time. 

INPUT:  Projectile  trajectory  characteristics,  ballistic 

dispersion,  fire  control  errors,  gun  rate-of-fire  and  target 
vulnerability . 
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OUTPUT :  Produces  printout  of  probability  of  survival  for  a  given 

time  increment. 

HARDWARE  AND  SOFTWARE: 

Computer :  Runs  on  CRAY  and  SEER  computers  with  the  UNIX 

operating  system. 

Storage :  904288  Bytes  for  executable  program. 

Peripherals :  1  printer  and  1  VT100  terminal. 

Programming  Language:  FORTRAN  77. 

Documentation :  Ketron  KFR  163-90,  Improved  FIRCON  Simulation, 

C.M.  Frank,  R.R.  Rudolph,  F.M.  Wiygul,  February  1990. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED,  but  data  can  be 
classified. 

GENERAL  DATA: 

Data  Base:  Time  needed  to  create  flight  paths  for  both 
aircraft  has  not  been  assessed  at  this  time. 

CPU  Time  per  Cycle:  1  minute  on  CRAY  II. 

Freguencv  of  Use:  At  this  time  the  model  is  just  beginning  to 
be  utilized,  but  the  urgency  of  the  application  of  this  to  the 
evaluation  process  is  pushing  us  to  use  it  ASAP. 
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DATE  IMPLEMENTED:  03/01/91 


TITLE:  Intelligence  Electronic  Warfare  Functioned  Area  Model  (IEWFAM) 
MODEL  TYPE :  Analysis 

PROPONENT:  U.S.  Army  Intelligence  Center,  Fort  Huachuca,  AZ  85631-7000 

POINT  OF  CONTACT:  Pamela  Kiley,  Attn:  ATSI-CDC-S,  AV  879-7212/7213 
Fort  Huachuca,  AZ  85631-7000 

PURPOSE:  The  IEWFAM  is  a  mid-level  resolution,  VIC  based,  combat 
simulation  that  portrays  intelligence  functions  in  terms  of  collection 
management,  sensors,  processing,  and  jamming.  The  model  supports  Ccmbat 
Development  activities  in  terms  of  evaluating  new  doctrine  and  competing 
strategies.  The  IEWFAM  is  a  Research  and  Evaluation  Tool  which  evaluates 
sensor,  processor,  and  jammer  effectiveness  against  target  sets.  The 
model  evaluates  IEW  force  capability  and  requirements  in  terms  of  mix 
effectiveness . 

DESCRIPTION: 

-  The  IEWFAM  evaluates  sensor  contribution  in  land,  air,  and  space. 

-  The  IEWFAM  is  a  corps  level  model.  The  contribution  of  theater  assets 
is  evaluated  in  an  aggregated  fashion. 

-  The  IEWFAM  utilizes  the  same  4km  terrain  hexes  utilized  by  the  VIC 
model.  Both  day  and  night  are  represented,  and  weather  is  represented  to 
a  limited  degree. 

-  The  model  plays  a  Blue  corps  against  a  Red  army.  Combined  or  joint 
forces  are  not  specifically  represented,  but  could  be. 

-  The  IEWFAM  evaluates  a  conventional  scenario.  The  chemical  and 
biological  module  can  either  be  turned  on  or  off  depending  on  the  desired 
level  of  detail. 

-  ECM,  Collection,  Collection  Management,  and  Processing  and  Analysis . 

-  Quits  are  usually  represented  at  the  battalion  level.  An  individual 
piece  of  equipment  (sensor)  can  be  represented,  but  it  is  associated  with 
a  parent  unit  for  processes  such  as  attrition  and  movement.  Flight 
profiles  of  specific  air  vehicles  are  explicitly  represented. 

CONSTRUCTION: 

-  Human  participation  is  not  required  once  the  simulation  has  initiated. 
An  interrupt  mode  has  been  built  into  VIC,  but  it  is  not  normally  used 
when  running  the  IEWFAM.  The  model  is  event-driven  and  changes  occur 
based  on  an  external  events  file  and  internal  events. 

-  IEWFAM  is  an  event-stepped,  dynamic  model. 

-  IEWFAM  is  a  deterministic  model  which  generates  a  value  as  a  function 
of  an  expected  value. 

-  The  IEWFAM  is  a  two-sided  model  in  which  all  processes  are  represented 
for  both  sides,  but  data  inputs  can  be  varied. 

LTMTTATICNS :  IEWFAM  validation  is  still  ongoing,  and  all  limitations 
have  not  yet  been  delineated.  Currently,  the  model  is  only  configured  to 
represent  a  European  environment.  Run  time  is  excessivly  long. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  Planned  improvements  include: 
facilitating  scenario  changes,  the  inclusion  of  HUMENT  representation 
through  AI  means  and  parrellization  of  processing  to  speed  up  run  times. 

INPUT:  The  IEWFAM  is  extremely  data  intensive.  In  addition  to  the  data 
required  for  the  ccmbat  portions  of  VIC  (scenario,  weapons,  units  etc.) 
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intelligence  specific  data  include:  requirements  nodes,  de tec tables, 
detectable  thresholds,  sensor  parametric  data,  processing  queues  and 
thresholds,  and  initial  perceived  threat. 

OUTPUT:  The  output  is  available  cn  magnetic  tape  which  is  loaded  into  an 
Ingres  data  base  which  is  part  of  the  IEWFAM  post  processor.  The  post 
processor  allows  the  user  to  access  the  data  through  preprogrammed  queries 
or  through  adhoc  SQL  commands.  The  data  can  be  displayed  in  tabular 
format,  in  relation  to  a  map  background,  or  in  carmen  business  statistical 
format. 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS):  SUN  IV  /  Unix 

STORAGE:  Minimum  storage  requirement  is  approximately  2  gigabytes 

PERIPHERALS:  Color  graphics  monitor  or  large  screen  projection  system 
and  printer  as  desired. 

PROGRAMMING  LANGUAGE:  SIMSCRIPT 

DOCUMENTATION:  Limited  documentation  is  available.  Documentation  cycle 
is  not  yet  complete . 

SECURITY  CLASS IFICATTCN:  The  code  is  UNCLASSIFIED,  but  the  input  data  is 
at  the  secret  level  and  can  be  upgraded  to  the  SCI  level. 

GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE:  Force  laydown  one  man  month.  System  characteristics  1/2  man 
month. 


CPU  TIME  PER  CYCLE:  Model  currently  running  approximately  1:1  for 
limited  periods.  Hardware  RAM  drives  run  time. 

DATA  OUTPUT  ANALYSIS:  TBD. 

FREQUENCY  OF  USE:  Model  is  currently  being  used  daily.  Expect  heavy 
usage  for  study  support  once  validation  is  complete . 

USERS:  Intelligence  Center  is  the  primary  user.  TRAC-WSMR  is  using 
portions  of  the  model  to  support  sane  studies. 

OCMMENTS:  IEWFAM  is  closely  linked  to  VIC.  IEWFAM  cannot  run  as  a 
stand  alone  model  without  the  VIC  combat  driver.  Changes  to  VIC  code  must 
be  incorporated  as  they  occur. 
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TITLE:  JANUS-Rand 


DATE  IMPLEMENTED:  1988. 


MODEL  TYPE:  Analysis. 

PROPONENT :  BGWG  Section,  CA4  Division,  RARDE,  Fort  Halstead, 

Kent,  England,  U.K. 

POINT  OF  CONTACT:  J.  Saunders,  CA4,  RARDE,  Fort  Halstead,  Kent, 
U.K.,  0959-32222,  ext  2924. 

PURPOSE :  JANUS  R  is  a  research  and  evaluation  tool,  dealing 

primarily  with  weapon  systems  development  and  effectiveness.  It 
can  also  be  used  to  assess  force  capability  and  requirements, 
dealing  with  courses  of  action,  mix  effectiveness  and  resource 
planning  and  can  be  used  for  the  study  of  tactics. 

DESCRIPTION: 

Domain :  Land  and  land/air. 

Span :  Local. 

Environment :  Resolution  depends  on  total  are  included  in  game 

e.g.  30km  x  30km  has  50km  resolution  and  60km  x  60km  has  100m 
resolution.  Terrain  features  include  spot  heights,  7  types  of 
vegetation,  7  types  of  building,  rivers,  roads,  bridges,  and 
obstacles.  The  model  can  har.  ’e  any  time  of  day  in  any  weather 
conditions . 

Force  Composition:  Up  to  and  including  Brigade  level. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Any  conventional  missions  within  the  domain. 

Level  of  Detail  of  Processes  and  Entities:  The  lowest  entities 
modelled  are  individual  men,  vehicles  or  aircraft,  though  men  are 
usually  grouped  into  small  teams.  Attrition,  movement,  target 
acquisition  and  logistics  are  modelled  for  each  entity. 

CONSTRUCTION: 

Human  Participation:  Required  for  decisions,  though  the  model 
would  continue  to  run  without  a  decision. 

Time  Processing:  Processing  is  dynamic,  the  model  uses  event 
stepping . 

Treatment  of  Randomness:  The  model  is  stochastic,  it  uses  the 
Monte  Carlo  method. 

Sidedness :  The  model  is  two-sided  and  symmetric. 


LIMITATIONS :  Does  not  model  C3I  in  any  detail. 

PLANNED  IMPROVEMENTS /MODIFICATIONS:  A  night  model  and  the 
introduction  of  different  kill  categories  are  to  be  introduced. 

A  modification  to  the  graphics  is  underway  to  increase  the  number 
of  colors  available.  There  are  some  30  other  changes  to  be  made, 
that  have  been  identified. 

INPUT. :  Terrain  data,  weather  data,  system  and  weapon 

characteristics  including  attrition  data,  mobility  data  and 
activity  timings,  smoke  and  dust  data. 

OUTPUT ;  system  status  as.  requested  during  the  game.  Records  cf 
all  direct  fire  and  indirect  fire  events,  mine  encounters  and 
detections  can  be  printed.  The  game  can  be  rerun  and  limited 
analysis  done.  A  new  post-processor  using  a  database  is  to  be 
developed . 

HARDWARE  AND  SOFTWARE: 

Computer :  Designed  to  run  on  a  VAX  computer  with  a  VMS 

operating  system. 

Storage :  256  Mb . 

Peripherals :  The  minimum  requirement  is  2  graphics  monitors,  1 

printer,  and  2  VT  series  terminals. 

Programming  Language :  VAX  FORTRAN . 

Documentation :  There  is  a  user's  guide  and  a  technical 

description  of  those  changes  made  since  acquisition  of  JANUS  T. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED,  database  classified 
SECRET. 

GENERAL  DATA: 

Data  Base:  About  2  man  years  for  the  first  study,  additional 
data  for  subsequent  studies  depends  on  study  but  varies  between  1 
&  6  man  months . 

CPU  Time  per  Cycle:  Form  3  to  6  minutes  of  processor  time  per 
minute  or  game  time  (on  a  VAX-785). 

Data  Output  Analysis:  Postprocessor  aids  in  analysis  of 
output . 

Frequency  of  Use:  Either  1  or  2  series  of  games  per  year, 
consisting  of  about  20  games  each. 

Users :  BGWG  section,  CA4  Division  in  response  to  requests  for 

studies  by  a  series  sponsor  from  within  the  MOD. 

Comments :  JANUS  R  is  a  development  of  JANUS  T,  contacts  with 

TRAC-WSMR  are  maintained. 


141 


DATE  TMPT .FMFNTED :  10/01/90 


TITLE :  Janus -Army 

MX>EL  TYPE:  Analysis  and  training  and  education 

PRQPCNENT:  TRADOC  Analysis  Ccrnmand  (TRAC-WSMR),  White  Sands  Missile 
Flange,  M4 

POINT  OF  CCNTACT:  Charles  Lee  Kirby,  ATRC-WEB,  (505)  678-4949, 

AV  258-4949 

PURPOSE:  Janus-Army  has  been  developed  primarily  as  an  analysis  tool  to 
support  Cost  and  Operational  Effectiveness  Analyses,  analysis  of  tactics 
and  doctrine  aixi  other  Army  studies.  It  is  also  used  as  a  high  resolution 
scenario  generator,  <3DP  evaluator,  and  CPX  driver.  Janus-Army  development 
has  also  responded  to  the  requirement  to  use  the  game  as  a  seminar  and 
classroom  educational  tool  for  company,  battalion  and  brigade  commanders. 

DESCRIPTION: 

Domain:  Land,  air  and  naval  support  of  land  operations 
Span:  Individual  system  through  brigade  force 

Environment:  Time  of  day,  DMA  digitized  terrain  topography,  weather 
conditions,  terrain  surface  features  include  vegetation,  bodies  of  water, 
cities,  roads  and  rivers,  obscuration,  obstacles,  and  non-persistent 
chemicals. 

Force  Composition:  Joint  and  combined  forces  for  both  RED  and  BLUE. 
Scope  of  Conflict:  RED  and  BLUE  conventional,  seme  chemical  and  seme 
unconventional  weapons. 

Mission  Area:  Combined  Arms  Combat  including  CAS,  airlift,  ground 
maneuver  and  indirect  fire  weapons. 

Level  of  Detail  of  Processes  and  Entities: 

Entities:  All  engagements  are  resolved  at  the  individual  system 
or  soldier  level.  Units  can  be  homogeneously  aggregated  to  expedite  play. 

Processes:  Janus-Army  processes  are  stochastic.  The  environment, 
search  and  detection,  and  attrition  processes  are  modeled  at  the  highest 
level  of  resolution  possible  within  the  constraints  of  data  and  hardware. 

OBSTRUCTION: 

Human  Participation:  Required  for  decisions  and  processes.  The  game 
does  not  wait  for  a  decision  to  be  made. 

Time  Processing:  Dynamic,  time  preserving  event  stepped  model. 

Treatment  of  Randomness:  Stochastic:  a  combination  of  direct 
computation  and  Monte  Carlo  techniques. 

Sideness:  Two  sided,  asyrrmetric,  with  both  side  capable  of  reacting. 

LIMITATIONS :  600  units  per  side.  Units  must  be  homogeneous,  one  or  more 

systems . 

PLANNED  IMPROVEMENTS  AND  MXIFICATICNS :  Simplify  data  base  maintenance; 
alio/  heterogeneous  aggregate  units:  and  separate  initial  planning  from 
game  execution. 

INPUT:  Static  -  Weapon  and  system  operational  characteristics,  weapons 
effects,  sensor  performance  (weather  dependent),  radar  performance  vs  a/c, 
terrain,  smoke  and  dust  parameters  (weather  dependent),  chemical  weapon 
parameters,  minefield  parameters  and  effects. 

Scenario  dependent  -  force  size  and  composition,  initial  positions  of 
units,  barriers  and  prepared  positions  and  preplanned  artillery. 
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Dynamic  -  movement  routes,  unit  states,  search  sectors,  and  artillery 

OUTPUT:  All  artillery  and  direct  fire  events,  all  kill  events,  all 
minefields  encounters  and  breaching  activity  by  unit,  all  detection  events 
and  all  events  related  to  heat  stress,  protective  actions  and  use  of 
chemicals  are  recorded  on  disk.  The  standard  post  processor  produces 
summary  artillery  and  direct  fire  reports,  killer  victim  scoreboard,  force 
loss  analysis,  system  exchange  ratios,  system  contribution,  detection 
scoreboard,  and  engagement  range  analysis. 

HARDWARE  AND  SOFTWARE: 

OCMPUTER  (OS):  VAX/VMS 

STORAGE:  16  Mbytes  (CPU) ,  500  Mbytes  (disk) 

PERIPHERALS:  4-8  Tektronix  4225  1 9"  color  graphic  terminals  with  data 
tablets,  4-8  VT320  terminals,  1  line  printer,  2-4  table  top  printers. 

PROGRAMMING  LANGUAGE:  FORTRAN 

DOCUMENTATION:  1986  User  Manual  with  updating  memoranda. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED 
GENERAL  DATA  AND  TIME  REQUIREMENTS : 

DATABASE:  Initial  preparation,  2  to  4  man  months.  Updates,  2  to  10 
man  days. 

CPU  TIME  PER  CYCLE:  CPU  and  scenario  dependent  -  MV3800  will  run 
brigade  scenarios  at  recil  time. 

DATA  OUTPUT  ANALYSIS:  Study  and  analyst  dependent. 

FREQUENCY  OF  USE :  Continuous 

USERS:  TRAC-WSMR;  TRAC-MIRY;  FT  Rucker;  DLOR,  Canada;  AWGC  and  WSRL, 
Australia;  CAD,  France;  West  Point;  FT  Leonard  Wood;  I.D.A.;  and  SOUIHOCM. 

COMMENTS:  Janus-Army  replaces  Janus (T).  FT  Benning;  ET  Knox;  FT  Sill; 
Rand  Arroyo;  TRAC-WSMR;  TRAC-SWC;  and  RARDE,  UK  still  use  Janus(T). 
Software  support  for  Janus(T)  will  continue  until  July  1991.  Inquires 
for  obtaining  the  model  and  supporting  data  bases  should  be  addressed  to 
TRAC -TOD,  Ft.  Leavenworth,  KS  66027-5200  or  call  AV  552-5511  or 
commercial  91 3-684-551 1 . 
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TITLE:  Low-Energy  Laser  Weapon  Simulation  -  LELAWS 

DATE  IMPLEMENTED:  July  1981. 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.S.  Army  Materiel  Systems  Analysis  Activity. 

POINT  OF  CONTACT:  Dir,  USAMSAA,  ATTN:  AMXSY-CS,  B.  Bradley, 
Aberdeen  Proving  Ground,  MD  21005-5071,  AV  298-6231/301-278-6231 

PURPOSE :  A  research  and  evaluation  tool  used  during  system 

development.  This  program  models  the  propagation  of  pulse  energy 
from  a  low-energy  laser  weapon  (or  laser  range  finder  or  laser 
designator)  through  a  turbulent  atmosphere  to  a  point  in  the 
far-field  where  this  energy  is  received  by  a  target  sensor.  The 
target  sensor  could  be  the  unaided  eye,  the  optically-aided  eye, 
an  image  intensifier  or  converter,  or  a  TV  system.  The  primary 
measure  of  effectiveness  generated  by  the  model  is  the 
probability  that  a  given  pulse  (or  train  of  pulses)  reaching  the 
sensor  will  exceed  the  damage  threshold  of  the  sensor.  The  model 
is  used  primarily  for  the  evaluation  of  item-level  performance  of 
low-level  laser  weapons  in  the  anti-sensor  role.  In  addition, 
the  model  can  also  be  used  in  laser  hazard/safety  studies  to 
estimate  the  level  of  laser  eye  hazard  associated  with  low-energy 
lasers  on  the  battlefield  or  during  training  exercises. 

DESCRIPTION:  LELAWS  is  a  completely  digital,  one-on-one 

simulation  of  a  low-energy  laser  weapon  operating  in  the 
anti-sensor  role.  Both  land  and  air-based  targets  sensors  can  be 
in  the  model.  Although  the  model  was  designed  primarily  for  the 
one-on-one  engagement,  it  can  be  used  to  predict  effectiveness 
estimates  for  one  laser  versus  several  sensors. 

Domain:  Land,  air,  sea. 

Span:  Individual. 

Environment :  Atmospheric  effects. 

Force  Composition:  Item. 

Scope  of  Conflict:  Any. 

Mission  Area:  Direct  fire  ground-ground,  ground-air,  air- 
ground  . 

Level  of  Detail  of  Processes  and  Entities: 

Entity :  Item. 

Processes :  Sensor  damage. 


CONSTRUCTION : 

Human  Participation:  Not  permitted. 


Time  Processing:  Static. 

Treatment  of  Randomness:  Stochastic,  Monte  Carlo. 

Sidedness:  One-sided. 

LIMITATIONS :  Pulsed  lasers  only;  Divergent  beams  only; 

Low-energy  lasers  only  (i.e.,  no  thermal  blooming);  Smoke  effects 
not  presently  included. 

PLANNED  IMPROVEMENTS /MODIFICATIONS :  We  are  currently  adding  CW 
lasers . 

INPUT :  Laser  weapon  characteristics;  Target  sensor 

characteristics;  Sensor  damage  thresholds;  Atmospheric 
conditions;  Engagement  parameters. 

OUTPUT :  Detailed  echo  of  input  data;  Laser  beam-spreading 

parameters  as  a  function  of  range;  Tables  of  sensor  damage 
probability  as  a  function  of  range,  visibility,  damage  level,  and 
number  of  pulses  fired;  Optional  output  includes  power-fading 
distributions  for  each  of  the  primary  phenomena  which  affect  the 
laser  beam. 

HARDWARE  AND  SOFTWARE: 

Computer  (OS):  CRAY-2  (UNIX),  IBM-PC  (MS  DOS). 

Storage  required:  47K. 

Peripherals :  None . 

Programming  Language:  FORTRAN  IV. 

Documentation :  Draft. 

SECURITY  CLASSIFICATION:  (Model  without  data)  UNCLASSIFIED. 
GENERAL  DATA: 

Database :  Several  man-weeks  to  acquire  data  base;  less  than 

one  hour  to  structure  data  in  model  input  format. 

CPU  Time  per  Cycle:  1-2  seconds  per  single  engagement. 

Data  Output  Analysis:  Few  minutes. 
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DATE  TMPLFMFNTED:  01/01/79 


TITLE:  Maintenance  Capability  Attack  Model  (MACATAK) 

MODEL  TYPE :  Analysis 

PROPONENT:  TRADOC  Analysis  Command,  Ft  Lee  (TRAC-LEE) 

POINT  OF  CONTACT:  Bruce  E.  Lasswell,  AV  687-1050,  Ft  Lee,  VA  23801 

PURPOSE:  To  measure  the  survivability  and  vulnerability  of  division-level 
maintenance  elements  in  conventional,  chemical,  and  nuclear  environments . 
The  model  assesses  the  effectiveness  of  the  maintenance  system  as  it 
experiences  attacks  both  on  the  end  item  it  supports  and  on  the  system 
itself. 

DESCRIPTION:  This  is  a  stochastic,  discrete  event,  high  resolution 
maintenance  simulation  created  using  MAWLOGS  Modeling  System.  It  plays 
multi-echelon  maintenance  activities  with  explicit  skills,  test  equipment, 
and  DX  or  LRU  inventories.  Lift  equipment  and  ASL-PLL-NSL  parts  are  played 
generically.  Repair  actions  and  combat  damage  can  be  represented  in  great 
detail. 

CONSTRUCTION: 

Human  Participation:  Not  required — scheduled  changes. 

Time  Processing:  Dynamic,  event-step. 

Treatment  of  Randomness:  Eizher  stochastic,  Monte  Carlo  or 
deterministic 

Sidedness :  One-sided . 

LIMITATIONS :  Data  set  can  be  extensive.  Not  directly  related  to  combat 
models. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  None. 

INPUT:  Number  and  type  of  equipment  in  each  using  unit;  number  and  MDS 
of  maintenance  personnel;  inventory  of  DX  components  at  each  maintenance 
activity;  equipment  usage  rates  and  fai  re  rates;  maintenance  action 
information  such  as  time  to  repair,  fre  -ency  of  occurrence,  and  contact 
teams;  time  it  takes  for  parts  to  arrive;  scenario. 

OUTPUT:  Tabular  printouts  of  probable  equipment  availability;  listing  of 
equipment  maintenance  TAT;  TAT  broken  into  function  segments;  printouts  of 
of  queue  sizes  for  parts,  skills,  and  equipment  as  a  function  of  time.  A 
binary  transaction  file  is  created  for  additional  postprocessing. 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS):  VAX  11/780,  SUN  4/280. 

STORAGE :  Variable . 

PERIPHERALS:  Printer  and  tape  drive. 

PROGRAMING  LANGUAGE:  FORTRAN  77. 

DOCUMENTATION:  User's  Guide  for  MACATAK  (DLSIE  41425-MA), 

Programmers'  Guide  for  MACATAK  (DLSIE  41425-MB). 

OTHER  OCTMENTS:  MACATAK  was  created  using  the  Models  of  the  Army 
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Worldwide  Logistics  System  (MAWLOGS). 

SECURITY  CLASSIFICATION :  UNCLASSIFIED. 

GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE;  N/A. 

CPU  TIME  PER  CYCLE :  Varies . 

DATA  OUTPUT  ANALYSIS:  Varies. 

FREQUENCY  OF  USE:  As  needed. 

USERS:  Proponent;  U.S.  Amy  Combined  Arms  Support  Command;  U.S.  Army 
Ordnance  Missile  and  Munitions  School;  BEM  Corporation. 

COMMENTS:  Government  agencies  can  obtain  MACATAK  with  a  signed 
memorandun  of  agreement.  Government  Contractors  with  a  valid  contract 
requiring  the  use  of  MACATAK  can  also  obtain  the  model  with  the  approval 
of  the  TRAC  Commanding  General.  Inquiries  for  obtaining  the  model  and 
supporting  data  bases  should  be  addressed  to  TRAC-TOD,  Ft.  Leavenworth,  KS 
66027-5200  or  call  AV  552-5511  or  commercial  913-684-5511. 


147 


DATE  TMPLFMENTED:  01/31/91 


TITLE:  Maintenance  Model  (MAMD) 

M3DEL  TYPE:  Analysis 

PROPONENT:  U.S.  Army  Combined  Arms  Support  Command  (USACASCCM),  Ft  Lee  VA 

POINT  OF  CONTACT:  Dr.  James  Blowers,  CASCCM,  ATTN:  ATCL-CMM,  AV  687-3063 

PURPOSE:  Model  the  wartime  operation  and  maintenance  of  wheeled  vehicles 
in  a  heavy  Division  slice  through  EAC.  Designed  for  the  primary  purpose 
of  determining  maintenance  manpower  requirements. 

DESCRIPTION: 

Domain:  Heavy  division  slice  of  a  corps  throught  EAC,  land  only. 

Span:  Division  slice  through  EAC. 

Environment:  Time,  usage  profile  (stop,  move,  idle). 

Force  Composition:  Wheeled  vehicles. 

Scope  of  Conflict:  Conventional . 

Mission  Area:  Weapons  not  modelled. 

Level  of  Detail:  Individual  vehicle  operation  and  maintenance. 
OCNSTRUCnCN: 

Human  Participation:  Not  required,  not  permitted  once  run  submitted. 
Time  Processing:  Dynamic  discrete  event. 

Treatment  of  Randomness:  Deterministic,  generates  values  based  on 
distribution. 

Sideness :  One-s ided . 

LIMITATIONS :  No  geography.  No  combat  damage. 

PLANNED  IMPROVEMENTS  AND  MJDIFICATTCNS:  User's  Guide,  Mar  91 

INPUT:  Comprehens i ve  LIN  maintenance  data,  usage  data,  force  structure, 
part  availability  and  delay. 

OUTPUT:  Annual  maintenance  man-hours  by  level  of  maintenance  by  MDS  by 
LIN  Operational  availability,  wait  and  queue  length  data. 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS):  VAX  11/780,  VMS 

STORAGE:  Model  +  data  +  to  run  =  10,000  blocks/  500k  bytes  data  arrays 
etc.  virtual 

PROGRAMMING  LANGUAGE:  Discrete  Event  SLAM  (FORTRAN) 

DOCUMENTATION:  User's  Guide  (Mar  91),  Model  docunentation  (Jan  91) 
SECURITY  CLASSIFICATION :  UNCLASSIFIED 
GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE:  As  updates  require 

CPU  TIME  PER  CYCLE;  4  hours  24  minutes  to  run  30  days 
DATA  OUTPUT  ANALYSIS:  4  hours 
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FREQUENCE  OF  USE :  As  required 


USERS:  CASCCM,  OC&S 

CX^MENTS:  Originally  developed  to  support  MARC  program. 
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TITLE:  Maritime  Campaign  Program  (MCP) 


DATE  IMPLEMENTED:  1982 


MODEL  TYPE:  Analysis 

PROPONENT :  DOAE  (some  program  maintenance  work  contracted  out  to  CORDA) 

POINT  OF  CONTACT:  John  G  Oven,  Byfleet  Mil  or  09323  41199  ext 

PURPOSE:  MCP  is  a  theatre  level  model  of  naval  operations,  used  to  evaluate 

the  performance  of  different  force  mixes  with  different  veapon  system  fits. 

DESCRIPTION: 

Domain:  Sea  and  related  Air  operations. 

Span:  Theatre  level;  any  theatre  depending  on  data  base. 

Environment:  Network  based;  nodes  represent  different  sea  or  coastal  areas  or 

land  areas  which  contain  air  bases.  Nodes  have  different  environment  types 
for  ASW  purposes,  and  different  probabilities  of  being  able  to  resupply  at 
sea;  these  are  constant  throughout  the  war. 

Force  Composition:  Any  combination  of  the  vessel  and  aircraft  types 

represented  in  the  scenario,  BLUE  and  RED. 

Scope  of  Conflict:  Primarily  conventional  anti-ship,  anti-submarine, 

anti-aircraft  and  airfield  attack,  weapons.  Nuclear  weapons  can  be  played,  but 
only  their  immediate  effects  on  units  and  bases  represented. 

Mission  Area:  Sea  control,  OTC  group  operations,  anti-submarine  barrier  and 
sweep  operations,  anti-shipping  airstrikes,  counter-air  interdiction,  combat 
air  patrol,  interception. 

Level  of  Detail  of  Processes  and  Entities:  Individual  ships  and  submarines, 
each  having  a  specified  weapons  fit,  are  modelled.  Vessels  are  combined  into 
groups  for  movement  and  combat  purposes  but  firing,  munition  consumption  and 
losses  are  assessed  for  each  individually.  Aircraft  are  assigned  to  missions, 
consume  munitions  and  take  losses  individually. 

CONSTRUCTION 


Human  Participation:  Once  the  scenario  data  files  have  been  set  up,  the  model 
is  usually  run  without  human  intervention.  However,  there  is  an  interactive 
mode  which  allows  the  user  to  change  units'  orders  during  the  campaign, 
overriding  those  wh^ch  the  model  would  otherwise  take  from  the  data  files. 


Time  Processing;  Dynamic,  event  stepped  model. 


Treatment  of  Randomness:  Stochastic,  Monte-Carlo  based.  Random  variation 
applied  to  movement  times.  All  detection  Monte-Carlo  based  on  data  parameters 
for  the  different  types  of  detection.  All  attrition  is  Monte-Carlo  based  on 
probabilities  of  kill  by  individual  weapons.  Model  runs  normally  400 
replications  of  the  campaign. 

Sidedness :  Two-sided,  symmetric. 

Limitations:  Does  not  model  logistics,  except  for  ship  munition  supplies. 
Does  not  model  command,  control  and  communications  (except  insofar  as  elements 
are  built  into  the  scenario  design). 

PLANNED  IMPROVEMENTS/MODIFICATIONS:  Consideration  is  being  given  to  including 
logistics  and  C3  modelling. 

INPUT:  Theatre  data  -  node  positions  and  interconnections,  ASW  environment 
type.  Craft  type  data  -  weapon  fit,  loading  and  kill  probabilities,  sensor 
fit  and  capability,  firing  policy,  speed.  Group  data  -  composition, 
deployment,  orders,  contingency  orders.  Air  data  -  air  base  complements 
(including  carriers),  aircraft  allocation  to  tasks,  aircrat  weapon  fit  and 
capability.  Mine  data  -  positions  and  capabilities. 

OUTPUT:  Tables  of  cumulative  statistics  over  all  replications  -  killer/victim 
scoreboards  by  target  type  or  group,  firer  craft  type,  group  or  weapon  type; 
munition  consumption;  craft  survival  times;  numbers  of  attacks  and  air  raids. 

HARDWARE  AND  SOFTWARE 


Computer:  Currently  runs  on  a  VAX  computer  with  a  VMS  operating  system. 

Storage:  Approximately  100,000  blocks  (50  megabytes)  not  including  databases. 

Peripherals:  Minimum  1  terminal  and  1  printer.  Interactive  mode  also 

required  1  SIGMEX  graphics  terminal.  Plotter  output  can  also  be  produced. 


Programming  Language:  FORTRAN  77.  Graphics  use  GKS  routines. 


Documentation: 


1.  DOAE  Memorandum  M82105,  October  1982,  DOAE  MCP  Summary  Description. 

2.  DOAE  Memorandum  M83101,  November  1983,  DOAE  MCP  Model  Description. 

3.  Various  DOAE  papers  describing  specific  model  improvements  since  1983. 
SECURITY  CLASSIFICATION:  Model  code  UNCLASSIFIED. 

GENERAL  DATA 


Time  Requirements: 

Data  Base:  Preparation  of  a  complete  data  set  from  scratch,  including 
scenario  development,  can  take  many  man-months.  Updating  or  refining  a 
scenario  for  a  new  study,  several  man-weeks  of  effort. 

CPU  Time  per  Cycle:  400  replications  of  a  10-day  campaign  takes  1%  hours  CPU 
time. 

Data  Output  Analysis:  Produces  summary  tables  of  cumulative  results  over 

replications,  usually  as  hard  copy.  Some  post-processor  programs. 

Frequency  of  Use:  In  continual  use  at  DOAE. 

Users:  DOAE  (Maritime  Campaign  Analysis  Section) 

Comments:  Input  data  on  sensor  and  weapon  performance  drawn  from  more 

detailed  lower  level  models  run  at  DOAE  and  elsewhere. 


DATE  IMPLEMENTED:  02/01/91 


TITLE :  Medical  Evacuation  MARC  Model  (MEDEVAC) 
model  type  :  Analysis 

PROPONENT:  U.S.  Army  Combined  Arms  Support  Command  (USACASOCM),  Ft  Lee  VA 

POINT  OF  CONTACT:  Gerard  Petet,  CASCCM,  ATTN:  ATCL-CM1,  AV  687-1845 

PURPOSE:  This  analysis  provides  a  valid/audi table  method  of  determining 
the  Manpower  Requirements  Criteria  (MARC)  for  medical  evacuation  (MEDEVAC) 
operations  in  a  European,  mid- intensity  conflict  scenario.  This  study 
provides  the  factors  required  to  determine  the  minimum  number  of  essential 
M3S  67J  -  Helicopter  Crew  Chiefs;  M3S  153B/D  -  UH1H/UH60  Helicopter  Pilots; 
M3S  91 A  -  Medical  Specialists;  and  MOS  91B  -  Medical  NGO's  that  are  needed 
to  staff  medical  evacuation  units  in  order  to  accomplish  their  wartime 
mission. 

DESCRIPTION :  To  determine  MARC  requirements,  a  complex  model  was 
developed  using  the  Simulation  Language  for  alternative  Modeling  (SLAM). 
This  model  simulates  a  division  slice  through  the  Echelon  Above  Corps 
(EAC)  and  the  patient  flow  from  the  Foward  Line  of  Troops  (FLOT)  to  the 
(XMMZ  Hospital  using  both  air  and  ground  ambulances  in  a  wartime 
environment.  The  total  operational  hours  per  day  per  air  and  ground 
ambulance  required  for  MEDEVAC  were  recorded  by  type  air/ground  ambulance 
for  each  level  (CP,  BAS,  BSA,  etc.).  These  operational  hours,  in  addition 
to  APIVMH  were  used  to  determine  M3S  requirements. 

CONSTRUCTION:  No  human  participation  required  during  simulation  run. 

Model  is  interruptable,  dynamic  (event-step  form),  stochastic  and 
two-sided  (symmetric). 

LIMITATIONS :  Division  slice  of  corps.  30  day  -  no  warmups.  Five  air 
and  five  ground  ambulances  maximum. 

PLANNED  IMPROVEMENTS  AND  M3DIFICATICNS :  User's  Guide  Dec  90. 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS) :  VAX  1 1 /780 

STORAGE:  3,000  blocks 

PERIPHERALS :  Printer 

PROGRAMMING  LANGUAGE:  SLAM,  FORTRAN 

DOCUMENTATION :  User's  Guide,  Dec  90 

SECURITY  CLASSIFICATION:  UNCLASSIFIED 

GENERAL  DATA  AND  TIME  REQUIREMENTS : 

DATABASE :  8  hours 

CPU  TIME  PER  CYCLE :  30  minutes 

DATA  OUTPUT  ANALYSIS:  1  hour 
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FREQUENCY  OF  USE:  Continual 

USERS:  Academy  of  Health  Sciences,  CASCCM 
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TITLE:  Micro  FASTAL 


Date  Implemented:  1987. 


MODEL  TYPE:  Analytical. 

PROPONENT:  U.S.  Army  Concepts  Analysis  Agency,  Attn:  Forces 

Directorate,  8120  Woodmont  Avenue,  Bethesda,  MD  20814-2797. 

POINT  OF  CONTACT-  Mr.  Raymond  G.  McDowall,  (AV)  295-1658. 

PURPOSE :  The  objective  of  Micro  FASTALS  is  to  develop  the 

balanced  support  force  requirements  for  a  specified  combat  force 
Micro  FASTALS  is  used  primarily  for  force  in  a  contingency  type 
operation  Micro  FASTALS  was  developed  from  the  larger  FASTALS 
model  and  designed  to  run  on  a  personal  computer  using  a 
spreadsheet  format. 

DESCRIPTION: 

Dome  n :  Land . 

Span :  Each  run  accommodates  one  theater  with  a  specified 

comtat  force  in  a  combat  scenario. 

Environment :  Theater  dependent. 

Force  Composition:  Spec- fied  by  study  sponsor  and  used  to 
generate  requirements  for  Army  logistical  units. 

Scope  of  Conflict:  N/A. 

Mission  Area:  Micro  FASTALS  is  a  deterministic  computer 
program  that  was  developed  to  generate  the  Army  support 
requirements  that  result  from  ■  a:  t  .  combat  simulation  in  a 
small  theater. 

Level  of  Detail  of  Processes  a  d__r  ,  ;  ;ies :  Support 
requirements  are  generated  for  eacn  nic  type  (functional  area) 
including  engineer,  chemical,  medic?!,  transportation,  ordnance, 
quartermaster,  et  al,  by  Standard  Requirements  Code  (SRC).  The 
workload  requirements  needed  to  sustain  the  forces  are  also 
generated  and  displayed  workloads  include  maintenance, 
construction,  supply  consumption,  transportation,  patient  care, 
personnel  replacements,  other. 

CONSTRUCTION: 

Human  Participation:  All  inputs  are  developed  by  functional 
area  analysts  prior  to  model  execution.  No  interaction  is 
permitted  during  model  execution. 

Time  Processing:  Dynamic,  one  time  period. 

Treatment  of  Randomness:  Deterministic. 
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Sidedness :  One  sided. 


LIMITATIONS :  Generalized  theater  network  (single  region);  no 

time-phasing  of  requirements;  no  attrition  to  combat /support 
units,  single  movement  of  units  and  supplies  from  point  of 
arrival  in  theater  to  destination. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  The  model  will  be 
expanded  to  handle  700  units  (up  from  300)  and  be  able  to 
generate  a  time-phased  troop  list  similar  to  the  larger  FASTALS 
models . 

INPUT:  The  following  data  base  in  magnetic  tape  form  are  used. 

Military  Traffic  Management  Command  weights  file,  Army  MARC 
Maintenance  Data  Base,  Force  Accounting  System  Unit  data,  and 
Consumption  factor  data  (provided  on  floppy  disks)  from  the  U.S. 
Army  Logistics  Center. 

OUTPUT :  Force  listing  is  in  the  form  of  a  troop  list  indicating 

unit  requirements  by  SRC. 

HARDWARE  AN!  SOFTWARE : 

Computer :  IBM  AT  or  equivalent. 

Storage :  1.5  megabytes. 

Peripherals :  Standard  or  high  density  disk  drives. 

Language :  LOTUS  123. 

Documentation :  User's  Manual. 


GENERAL  DATA: 

Data  Base:  One  man-week  or  more  depending  on  size  for  force 
and  complexity  of  theater  being  evaluated. 

CPU  Time  Per  Cycle:  Five  minutes. 

Data  Output  Analysis:  Two  days  or  more  depending  upon  theater 

Freguencv  of  Use:  Used  approximately  10  time  per  year  for 
quick  reaction  analyses. 

Users :  USACAA,  U.S.  Army  Logistics  Center,  U.S.  Army  Logistic 

Evaluation  Agency. 

Comments :  This  model  has  been  used  for  3  years  to  develop  the 

support  force  requirements  for  the  Army. 


Sidedness :  One  sided. 

LIMITATIONS :  Generalized  theater  network  (single  region);  no 

time-phasing  of  requirements;  no  attrition  to  combat /support 
units,  single  movement  of  units  and  supplies  from  point  of 
arrival  in  theater  to  destination. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  The  model  will  be 
expanded  to  handle  700  units  (up  from  300)  and  be  able  to 
generate  a  time-phased  troop  list  similar  to  the  larger  FASTALS 
models . 

INPUT:  The  following  data  base  in  magnetic  tape  form  are  used. 

Military  Traffic  Management  Command  weights  file,  Army  MARC 
Maintenance  Data  Base,  Force  Accounting  System  Unit  data,  and 
Consumption  factor  data  (provided  on  floppy  disks)  from  the  U.S. 
Army  Logistics  Center. 

OUTPUT:  Force  listing  is  in  the  form  of  a  troop  list  indicating 

unit  requirements  by  SRC. 

HARDWARE  AND  SOFTWARE: 

Computer :  IBM  AT  or  equivalent. 

Storage :  1.5  megabytes. 

Peripherals :  Standard  or  high  density  disk  drives. 

Language :  LOTUS  123. 

Documentation :  User's  Manual. 

GENERAL  DATA: 

Data  Base:  One  man-week  or  more  depending  on  size  for  force 
and  complexity  of  theater  being  evaluated. 

CPU  Time  Per  Cycle:  Five  minutes. 

Data  Output  Analysis:  Two  days  or  more  depending  upon  theater. 

Freguencv  of  Use:  Used  approximately  10  time  per  year  for 
quick  reaction  analyses. 

Users :  USACAA,  U.S.  Army  Logistics  Center,  U.S.  Army  Logistics 

Evaluation  Agency. 

Comments :  This  model  has  been  used  for  3  years  to  develop  the 

support  force  requirements  for  the  Army. 
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TITLE :  Minefields  and  Barriers  Combat  Simulation  -  MBCS 


DATE  IMPLEMENTED:  1980. 

MODEL  TYPE:  Analysis. 

PROPONENT :  CA4  Division,  RARDE,  Fort  Halstead. 

POINT  OF  CONTACT:  N.  Roberts,  RARDE  ext  2289. 

PURPOSE :  Research  and  Evaluation  of  weapon  systems 

effectiveness . 

DESCRIPTION: 

Domain :  Land. 

Span :  Local  (typically  up  to  10km  front). 

Environment :  Digitized  terrain,  representing  relief, 

vegetation  and  man-made  cover,  100m  resolution. 

Composition :  Heterogeneous  direct  fire  units,  and  "off-table" 

artillery . 

Scope :  Conventional. 

Mission  Area:  Direct  fire  battle. 

Level  of  Detail:  Individual  vehicles  and  GW  teams  represented. 
Location  and  state  of  all  relevant  mines  also  represented 
individually.  Direct  fire  attrition  is  modelled  in  detail  to  the 
individual  firing  and  impact.  Each  mine  encounter  explicitly 
modelled.  Movement  is  along  preplanned  routes,  with  speed  and 
acceleration  governed  by  a  simply  mobility  algorithm. 

CONSTRUCTION: 

Human  Participation:  Not  required  or  permitted. 

Time  Processing:  Event  sequenced. 

Treatment  of  Randomness:  Stochastic,  Monte  Carlo. 

Sidedness :  Two-sided,  symmetric. 

LIMITATIONS :  Limited  number  of  GW  types  represented  (i.e.  only 

CLOS  and  ripple-fire  Passive  Homer).  No  infantry  or  helicopters 
represented.  No  C3I. 


PLANNED  IMPROVEMENTS:  None. 


INPUT :  Vehicle  characteristics  (weight,  power,  dimensions, 
minefield  countermeasures  fitted);  Weapon  characteristics  (range, 
time  of  flight);  Minefield  and  barrier  data  (location,  mine 
density,  etc.);  Orbat,  deployment,  routes,  orders;  Probability 
data  (mine  lethality,  hit  and  kill  probabilities  for  DF  systems, 
artillery  and  APGMs). 

OUTPUT :  Killer/victim  tables,  by  replication  and  averaged; 

Firer/ target  tables;  Shots/kills  by  range;  Mine  encounter  and 
result  statistics;  Event  tract  (i.e.  blow  by  blow  account  of  the 
battle ) . 

HARDWARE  AND  SOFTWARE: 

Computer /OS:  VAX/VMS. 

Storage :  70Mb  (130,000  Blocks). 

Peripherals :  No  special  requirements. 

Language :  FORTRAN  IV,  reconditioned  to  FORTRAN  77. 

Documentation ;  User's  guide,  Programmer's  guide,  model 
definition . 

CLASSIFICATION:  UNCLASSIFIED. 

GENERAL  DATA: 

Time  Reouired: 

Data  Preparation:  Several  weeks. 

LOS  Preprocessor:  50  CPU  hrs . 

Preprocessor  ( exc  LOS ) :  2  CPU  hrs . 

Simulation:  -^1  1/4  hrs  per  replication  for  30  minute  battle. 

Analysis  Package:  Minimal. 

NB  Timings  are  based  on  a  complex  main  defensive  action  scenario. 
Freguencv  of  Use:  Rare. 

Users :  CA4  Division  RARDE.  AMSAA  have  a  version  which  differs 

in  several  respects,  specifically  artillery  and  allowed  size  of 
forces . 


TITLE:  Model  of  Aggregated  Central  Region  Operations.  MACRO 


TYPE:  Analytical. 

PROPONENTS:  LA2 ,  DOAE.  SHAPE  Technical  Centre 
POINT  OF  CONTACT:  H  Moran,  LA2 ,  DOAE 
PURPOSE: 

MACRO  is  a  research  and  analysis  tool  which  deals  with  force  capability  and 
requirements.  It  can  look  at  mixes  of  forces  and/or  force  effectiveness,  as 
well  as  absolute  magnitude  of  forces.  This  latter  allows  it  to  be  used  for 
policy  study  in  the  field  of  arms  control. 

DESCRIPTION 


Domain:  MACRO  is  primarily  a  Land  model  with  limited  representation  of  some 

air  operations. 

Span:  MACRO  is  a  theatre/regional  model. 

Environment :  MACRO  models  almost  no  environmental  features.  Options  include 

various  treatments  of  night. 

Scope  of  Conflict:  MACRO  models  conventional  warfare,  but  is  sufficiently 

flexible  to  be  used  to  model  some  aspects  of  nuclear  and  chemical  warfare. 

Mission  Area:  MACRO  models  the  aggregated  effects  of  Corps-level  combat. 

Level  of  Detail:  MACRO  uses  an  abstract  'points'  system,  but  these  are 

calculated  directly  from  the  numbers  of  tanks,  APCs  and  so  on  in  the  ORBAT. 
Aircraft  are  treated  individually.  The  lowest  level  of  entity  individually 
recognised  by  the  model  is  the  Corps  (in  some  cases,  the  model  has  been  used 
to  reflect  divisional  level  combat  however).  The  model  includes  attrition, 
FEBA  movement  and  commitment  of  reserves. 

CONSTRUCTION 


a.  Human  participation  is  not  required.  The  model  is  not  interruptable, 
but  a  data  file  does  exist  to  change  states  within  the  model  during  a  run. 


b. 

The 

model 

is 

c . 

The 

model 

is 

d. 

The 

model 

is 

a  dynamic  time  stepping  model, 
a  basically  deterministic  tool, 
two-sided. 
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LIMITATIONS 


The  model  has  very  little  detail. 
PLANNED  IMPROVEMENTS/MODIFICATIONS 


My  own  current  version  of  the  model  differs  from  the  original  implementation 
in  that  while  the  original  models  attack  helicopters  as  an  explicitly 
Corps-level  asset,  I  have  subsumed  them  into  the  ground  strengths  to  free  a 
'slot'  for  the  consideration  of  new  weapons. 

Uithin  LA2  three  further  modifications  are  planned/have  been  implemented. 
These  are  a  graphics  facility  to  show  what  is  going  on,  a  facility  to  allow 
reserves  to  be  deployed  across  corps  boundaries,  and  a  Blue  counter-attack 
facility. 

INPUT 


Strengths  for  each  corps,  depth  of  defensive  belts,  effectiveness  of  air 
sorties,  arrival  time  and  strength  of  reinforcements,  parameters  for  repair 
and  reconstruction  of  destroyed  units. 

HARDWARE  AND  SOFTWARE 


Computer;  Currently  running  on  a  VAX/VMS  system. 


Storage:  The  program  is  around  900  blocks;  input  data  around  30-60  blocks 
dependent  on  number  of  corps  being  modelled,  and  the  number  of  during-run 
changes.  The  output  is  dependent  on  the  length  of  war,  and  is  about  10  blocks 
per  day. 

Peripherals:  Keyboard  and  screen  to  get  the  data  in,  and  printer  to  get  it 
out  again. 


Programming  Language:  FORTRAN  77 

Documentation:  'High  Level  Modelling  of  the  Central  Region  Ground  Battle'. 

P  Harreschou.  STC  TN-013  FILE  REF  9980  D0AE  Lib  84193 
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Security  Classification;  Unclassified,  although  data  may  be  restricted  or 
higher,  as  will  the  corresponding  output. 

GENERAL  REQUIREMENTS 


Data  Base:  Vith  a  basecase  in  front  of  you  gross  changes  can  be  made  quickly 
and  easily,  although  certain  calculations  to  put  everything  into  MACRO 
strength  point  terms  are  necessary. 

CPU  Time*.  45  seconds  to  run  a  five  corps  war  for  twenty  days. 

Output  Analysis;  Anything  from  simple  study  of  FEBA  movement  to  advanced 
tracing  of  the  battle. 

Frequency  of  Use:  500  times  in  the  last  year,  and  at  least  50  in  support  of 
the  next  project. 

Users :  Several  within  DOAE,  STC,  IABG. 

Comments:  An  attempt  is  being  made  within  DOAE  to  link  MACRO  to  the  CAMAO 

air-campaign  model. 
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TITLE :  Modern  (Air  Defense)  Gun  Effectiveness  Model  -  MGEM 

DATE  IMPLEMENTED:  1981. 

PROPONENT :  U.S.  Army  Materiel  Systems  Analysis  Activity, 

Aberdeen  Proving  Ground,  MD  21005-5071. 

POINT  OF  CONTACT:  John  Meredith,  DSN  298-6405/(301)  278-6405. 

PURPOSE :  MGEM  is  a  Monte  Carlo  simulation  of  an  air  defense  gun 

which  utilizes  a  Kalman  filter  in  a  digital  fire  control.  The 
model  computes  gun  system  effectiveness  against  single  targets. 

GENERAL  DESCRIPTION: 

Domain :  Ground  to  air. 

Span :  Individual  gun  against  single,  passive  target. 

Environment :  Featureless. 

Force  Composition:  Single  air  defense  gun,  single  aircraft 
target . 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Conventional. 

Level  of  Detail  of  Processes  and  Entities;  Computation  of  kill 
probabilities  are  made  for  a  single  or  multiple  bursts  of  rounds 
from  the  gun.  The  basic  block  of  the  model  are  the  sensor,  the 
fire  control  computer,  the  gun  and  turret  servomechanisms,  the 
projectile  flyout,  and  the  damage  assessment.  The  target  state 
is  estimated  from  Modern  Control  Theory  by  Kalman  filter,  and 
prediction  can  be  either  first  or  second  order.  The  projectile's 
trajectory  is  computed  with  the  "3/2  Law",  and  the  vulnerable 
areas  are  represented  by  a  "shoebox". 

CONSTRUCTION: 

Human  Participation:  Not  reguired. 

Time  Processing:  Time  step. 

Treatment  of  Randomness:  Stochastic,  Monte  Carlo. 

Sidedness :  One-sided. 

LIMITATIONS :  Model  only  considers  lethality  of  bursts,  given 

bursts  are  fired. 

PLANNED  IMPROVEMENTS /MODIFICATIONS :  None . 
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INPUT:  Target  aircraft  position,  velocity  and  acceleration  as  a 

function  of  time.  Target  cardinal  direction  vulnerable  areas. 
Ballistic  dispersion.  Projectile  muzzle  velocity  and  drag 
factor.  Firing  doctrine. 

OUTPUT :  Probability  of  hit  and  kill  as  a  function  of  range. 

Ammunition  expended  as  a  function  of  range.  Gun  system  accuracy. 

HARDWARE  AND  SOFTWARE: 

Computer :  Any. 

Storage:  30K  words  of  core. 

Peripheral :  Input  device,  printer. 

Programming  Language:  FORTRAN. 

Documentation :  AMSAA  TR  360,  The  Air  Defense  Modern  Gun 

Effectiveness  Model,  September  1982,  AD  BQ65379. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED. 

GENERAL  DATA: 

Data  Base:  Input  requires  12  variables. 

CPU  Time  per  Cycle:  15  minutes  on  UNIVAC  1110. 

Data  Output  Analysis:  Output  contains  1  Page  of  values. 
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Title:  NATO  Deployment  Model  (NDM) 


Date  Implemented:  1971 


Model  Type:  Analysis 

Proponent:  Defence  Operational  Analysis  Establishment  (DOAE) 

Point  of  Contact:  Technical  Advisory  Group 

Purpose:  The  NDM  is  a  high  level  model  for  calculating  hov  a  defending  ground 
force  can  be  deployed  geographically  to  meet  a  range  of  possible  enemy  attacks 
in  the  most  effective  vay.  The  model  uses  an  iterative  mathematical 
programming  approach  to  represent  the  non-linearities  of  high  level  combat  and 
produce  an  optimal  answer  with  the  formulation. 

DESCRIPTION 


Domain:  Land  with  some  tactical  air  support 

Span:  Designed  originally  as  the  theatre  level  model,  it  can  also  be  used  at 
lower  level. 

Environment:  Relative  differences  in  combat  effectiveness  are  modelled  as  a 
function  of  the  geographic  area. 

Scope  of  Conflict:  The  model  has  been  designed  and  used  for  assessing 
conventional  conflicts  but  could  be  used  to  represent  some  aspects  of  conflict 
in  a  chemical  or  nuclear  environment. 

Level  of  Detail:  Analytical  relationships  derived  from  detailed  simulations 
represent  key  combat  effectiveness  parameters  for  rates  of  movement  by 
attacking  forces  and  the  capability  of  defenders.  Ground  forces  on  each  side 
are  modelled  as  aggregated  force  units  at  whatever  level  is  considered 
appropriate  for  the  study  in  hand.  For  the  air  forces,  individual  sorties  are 
modelled  in  support  of  ground  forces. 

CONSTRUCTION 


a.  Human  participation  is  not  required.  The  model  is  not  interruptable 
and  changes  to  decision  processes  need  to  form  part  of  the  input  data. 

b.  The  model  steps  forward  in  a  small  number  of  time  periods  which  are 
defined  in  the  input. 

c.  The  model  is  essentially  deterministic,  using  a  "mini/max"  approach 
to  the  range  of  possible  enemy  attack  plans. 

d.  The  model  is  two-sided. 

LIMITATIONS 


As  a  high  level  model,  many  features  are  aggregated  to  focus  attention  on  key 
elements.  There  is  no  explicit  representation  of  logistic  support  which  is 
contained  implicitly  in  the  force  units  represented  and  the  relative  combat 
effectiveness  calculated  accordingly. 

PLANNED  IMPROVEMENTS/MODIFICATION 


The  model  has  recently  been  retested  in  the  CFE  and  post  CFE  context  and  a 
graphics  facility  added  to  enhance  the  visual  perception  of  its  data  set  and 
output . 
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INPUT 


Total  available  forces  for  the  attacker  and  defender,  vith  relative  combat 
effectiveness,  movement  rates,  number  and  effectiveness  of  close  air  support 
sorties,  potential  reserve  locations,  movement  speeds,  decision  and  planning 
times  for  reserve  forces. 

OUTPUT 


The  graphics  shoving  air  and  ground  forces  deployment  and  movement  can  be 
supplemented  vith  hard  copy  output  on  the  data  sets  and  the  optimal  solution 
from  the  mathematical  programme. 

HARDWARE  &  SOFTWARE 


Computer:  Currently  running  on  a  VAX/VMS  system  and  under  MS  DOS  on  PC. 
Storage:  4MB  RAM  and  minimum  20  MB  hard  disc  for  PC  use. 

Peripherals:  VGA  graphics  terminal  and  lineprinter. 

Programming  Language:  Matrix  Generator  in  FORTRAN  77 

MPS  format  for  LAMPS  LP  package 
Graphics  run  under  WINDOWS  2.0 


Documentation: 

1.  NATO  Deployment  Model  1971  Version  DOAE  Memo  7210  April  1972. 

2.  NATO  Deployment  Model  Graphical  Interface  -  Source  and  Data  Listings 
August  1990. 

3.  User  Guide  to  the  NATO  Deployment  Model  Graphical  Interface  -  CD 
1095/7/2/TU1/1  July  1990. 

Security:  Unclassified,  although  data  may  be  higher,  as  vill  the  output. 


ses* 
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DATE  IMPLEMENTED:  11/15/90 


TITLE:  Network  Assessment  Model  (NAM) 

MDDFT-.  TYPE :  Analysis 

PROPONENT:  U.S.  Army  Signal  Center,  Directorate  of  Combat  Developments, 
Concepts  &  Studies  Division,  ATTN  :  ATZH-CDC  (Studies  Branch),  Fort 
Gordon,  GA  30905-5090 

POINT  OF  CCNTACT:  Commander,  U.S.  Army  Signal  Center,  ATTN:  ATZH-CDC 
(CPT  A.  Tabler) ,  Fort  Gordcn,  GA  30905-5090  AV  780-3782  CCMM  404-791-3782 

PURPOSE:  The  Network  Assessment  Model  (NAM)  is  a  high-resolution  tactical 
ccmmunicaticns  simulation  for  the  combat  developer.  NAM  allows  the 
analyst  to  simulate  the  deployment  of  C4  equipment  and  communicators  via  a 
digitized  terrain  map,  design  single  and  multichannel  radio  networks,  and 
evaluate  network  performance  against  known  ccmmunicaticns  requirements . 
NAM's  flexible  design  supports  the  analysis  of  ccmmunicaticns  issues 
including  network  architectures,  current/new  doctrine,  equipment  trade-off, 
equipment  reduction,  terrain  evaluation,  arid  force  design  (TO&E) . 

DESCRIPTION:  NAM  simulates  the  performance  of  the  Army's  current  and 
planned  tactical  caimunications  systems:  Mobile  Subscriber  Equipment, 
SINCGARS,  IHFR,  JITDS,  EPLRS,  TRI-TAC  (EAC-CIP).  NAM  emulates 
the  generation  and  completion  of  calls  between  battlefield  users 
throughout  all  Battlefield  Functional  Areas  (BFAs). 

NAM  handles  a  wide  variety  of  scenario  resolutions.  Via  roll-up 
techniques,  a  single  instrument  or  an  entire  Division  can  act  as  the 
smallest  entity.  Typically,  a  Division-  or  Corps-level  scenario  is 
modeled  with  phcne/radio/Battlefield  Automated  System  instrument  pools 
called  Operational  Facilities  (OPFACs)  forming  the  smallest  entity. 

NAM  uses  Defense  Mapping  Agency  (DMA)  DFAD  level-1  or  DIED  digitized 
terrain  data  coupled  with  the  Terrain  Integrated  Rough-Earth  Model  (TIREM) 
propagation  algor ithn  to  evaluate  radio  link  performance  between  2MHz  and 
20GHz.  NAM  computes  the  effects  of  Red  jammers,  terrain  and  distance 
that  reduce  or  elimate  radio  link  throughput. 

NAM  simulates  both  air  and  ground  communicators .  NAM  normally  models 
Army-only  units.  NAM  can  also  model  joint  and  allied  users  interfacing 
with  Army  networks  if  customized  OPFACs  and  associated  needlines  are 
built. 

NAM  has  been  developed  in  a  modular  format.  As  new  communications 
systems  are  proposed,  a  corresponding  module  can  be  inserted. 

OCNSTRUCTICN:  NAM  emulates  the  decisionmaking  process  the  Signal  Planner 
employs  in  supporting  Theater-and-below  battlefield  communicators.  Using 
a  menu/mouse-driven  interface,  the  analyst  deploys  Operational  Facilities 
(OPFACs)  that  describe  the  tactical  clustering  of  C4  users  and  equipment. 
After  the  networks  linking  these  OPFACs  have  been  engineered,  the  traffic 
offered  to  the  network  by  the  OPFACs'  subscribers  is  generated  and  sub¬ 
sequently  evaluated,  resulting  in  16  types  of  call  failure/ success  codes. 

NAM  has  five  major  modules.  MAINTENANCE  supports  the  building  and 
modifying  of  the  OPFAC  library,  and  the  extraction  of  cortnuni cations 
needlines.  SIMBUILD  facilitates  Blue  OPFAC  laydown,  network  engineering, 
and  Threat  EW  deployment.  SIMRUN  schedules,  routes,  and  evaluates  the 
the  networks'  throughput.  TACTICAL  SITUATION  DISPLAY  graphically  portrays 
the  networks'  performance  over  time.  POSTS IM  displays  sunmary  statistics. 
NAM  is  a  two-sided,  asymetric  model  in  that  only  the  Red  EW  is  portrayed. 

Most  interactive  works  involves  OPFAC  laydown.  The  analyst  can  stop, 
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adjust,  and  re-start  the  scenario  to  account  far  the  physical  destruction 
or  degradation  of  signed,  nodes  and  OPFACs. 

NAM's  primary  engine  is  a  dynamic,  event-step  call  scheduler.  Calling 
rates  are  based  on  frequency  of  transmission  values  described  in  the 
Communications  Data  Base  (CDB)  needlines.  A  negative  exponential  distri¬ 
bution  provides  the  scheduling  for  the  calls  to  be  initiated  and  evaluated 

LIMITATION:  5000  ENVTs,  2000  OPFACs,  500  MSE  Nodes,  100  SINGCARS  Nets. 
Other  limits  are  hardware  dependant.  Nodal/CPF PC  physical  attrition  is  not 
portrayed.  NAM' s  TIREM  implementation  does  not  account  for  foliage  effects 

PLANNED  IMPROVEMENTS  AND  MUDIFICATTCNS :  Planned  enhancements  include: 
upgraded  EPLRS  module  with  NCS  and  intercommunity  portrayal,  the  ability 
to  bulk  load  scenarios,  revised  threat  display,  EMC/ co-site  interference. 

INPUT:  OPFAC  locations  (type  and  quantity  of  C4  equipment),  CDB 
needlines  describing  amount  and  type  of  transmissions  between 
communicators,  Communications  backbone  and  extension  node  locations, 
communications  equipment  characteristics  (power  settings,  antenna  heights, 
sensitivity,  data  rates,  precedence,  trunk  capacity,  etc.)  ,  BAS 
characteristics  (data  rate,  auto  baud  detect),  DMA  digitized  terrain. 

OUTPUT:  Call  completion  logs,  call  routir.j  logs,  communications  node  and 
activity  level  logs  are  generated.  These  logs  can  be  processed  by  POSTS IM 
and  Tactical  Situation  Display  (TSD)  which  then  graphically  display  the 
performance  of  the  network(s)  under  evaluation.  Color  graphics  include 
bar  charts,  pie  charts  and  maps  with  network  diagram  and  throughput/ 
channel  occupancy  overlayed. 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS):  Silicon  Graphics  Inc.  (SGI)  4D- series  Graphics 
Workstations'  Unix  System  V  (IRIX). 

STORAGE:  Memory:  8  MB  RAM  Disk  Storage:  17  MB  executable  code 
and  (min)  10  MB  for  OPFAC,  CDB,  DMA  terrain  files,  NAM  input  files. 

PERIPHERALS:  RGB  Video  Printer  (Optional).  Relational  Data  Base 
Management  Software  (RDBMS)  package  (Optional-highly  recommended). 

PROGRAMMING  LANGUAGE:  C+  with  SGI-specific  graphics  extensions 

DOCUMENTATION:  Executive  Summary,  Methodology  Manual,  User  Handbook, 
Program  Maintenance  Manual 

uJlHek  COMMENTS:  The  simulation  input  module  also  runs  on  the  SGI  3000- 
series  workstations,  but  is  limited  in  capacity  and  processing  speed. 

SECURITY  CLASSIFICATION :  UNCLASSIFIED 

GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE:  Preparation  is  scenario  dependent.  Turnaround  time  greatly 
reduced  if  end-users  provide  detailed  scenario  inputs:  units,  locations 

CPU  TIME  PER  CYCLE:  Dependent  on  number  of  networks  and  nodes 
deployed.  For  a  Division- level  scenario,  1  hour  simulated  time  =  5  minutes 

DATA  OUTPUT  ANALYSIS:  With  an  RDBMS  package,  call  logs  and  other 
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output  files  can  be  tied  to  input  for  many  follow-on  investigations 
FREQUENCY  OF  USE:  Scenario  dependent. 


USERS :  The  Signal  Center  is  the  primary  user,  however,  copies  of 
NAM  software  have  been  sent  to  other  DoD  groups  for  their  evaluation. 

OCMMENTS:  Model  turnaround  time  is  extremely  dependent  on  the  amount 
of  high- resolution  inpxit  data  provided  by  the  end-user.  To  improve  turn¬ 
around  the  end-user  should  have  a  troop  list  with  units  (SRCs)  and 
(Operational  Facilities  (OPFACs)  already  found  in  the  (X©  and  NAM'e 
customized  OPFAC  Library.  Preparation  time  increases  if  customized  OPFACs 
and  needlines  have  to  be  created. 
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TITLE :  Nuclear  Fire  Planning  and  Assessment  Model  III 

NUFAM  III 

DATE  IMPLEMENTED:  1986. 

MODEL  TYPE :  Analysis. 

PROPONENT :  U.S.  Army  Concepts  Analysis  Agency,  8120  Woodmont 

Avenue,  Bethesda,  MD  20814-2797. 

POINT  OF  CONTACT:  Mr.  R.  Barrett,  (AV)  295-1670/(301)  295-1670. 

PURPOSE :  Research  and  evaluation  tool  for  corps  and 

theater-level  analysis.  Used  to  support  requirements  and 
capability  assessment  studies  of  tactical  nuclear  forces  arrayed 
in  context  of  a  theater  battle. 

DESCRIPTION: 

Domain :  U.S.  and  opposing  land  and  air  forces  on  a  corps-sized 

frontage.  Depth  to  500  km  from  FLOT. 

Span :  Corps  level  model  is  routinely  run  for  multiple  corps  to 

yield  theater-level  results. 

Environment :  User  defines  unit  locations  to  model  based  on 

terrain,  posture  and  scenario.  Model  does  not  represent  terrain 
features.  Population  centers  are  included  for  civilian 
damage/casualty  avoidance. 

Force  Composition:  Unit  sizes  are  defined  in  data  base. 
Intended  for  company  or  battalion  representation  of  units.  Both 
Red  and  Blue  units  represented. 

Scope  of  Conflict:  Nuclear  only.  Models  one  or  more  nuclear 
pulses  occurring  within  a  short  period  of  time  ( ? 1 2  hr).  Unit 
locations  remain  fixed,  although  the  effect  of  movement  is 
implicitly  represented.  No  conventional  attrition  occurs  during 
simulation,  but  should  be  reflected  in  unit  strength  prior  to 
nuclear  use. 

Mission  Area:  Nuclear  only. 

Level  of  Detail  of  Processes  and  Entities : 

Entities :  Company  or  battalion  maneuver  unit;  artillery  and 

missiles  by  firing  section  or  launcher,  aircraft  by  sorties 
from  airbases.  Defined  in  data  v>ase. 

Processes :  Target  acquisition,  detailed  fire  planning, 

execution  of  nuclear  pulses,  assessment  of  damage  to  units. 
Movement  implicitly  represented.  Damage  represented  is 
radiation  to  personnel  and  blast  to  equipment.  No  fallout. 
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Weapons  and  effects  are  defined  through  data  base  to  allow  new 
weapons  to  be  represented.  Fire  planning  criteria  defined 
through  data  base  to  allow  for  variations  in  fire  doctrine. 

Time :  Discrete  event  driven  model. 

CONSTRUCTION: 

Human  Participation:  Not  required  outside  of  preparation  of 
input  data. 

Time  Processing:  Dynamic  event  step. 

Treatment  of  Randomness:  Stochastic  (Monte  Carlo).  Ten  runs 
are  normally  required  to  yield  reasonable  means. 

Sidedness :  Two-sided,  symmetric  in  logic,  asymmetric  in  data 

output  values  and  data  driven  doctrine. 

LIMITATIONS :  No  conventional  or  chemical  play.  No  explicit 

movement  of  units. 

PLANNED  IMPROVEMENTS  AND  MODIFICATION:  Complete  revision  of 
model  to  produce  a  computationally  stochastic,  PC-based  model  is 
planned  for  completion  in  early  FY91 . 

INPUT:  Unit  locations  and  characteristics;  nuclear  weapons 

characteristics  and  effects.  Parameters  defining  acquisition, 
movement,  and  fire  planning  logic.  Size  and  location  of 
population  centers. 

OUTPUT:  Post-processor  produces  30  reports.  Typical  results  are 

units  acquired,  engaged,  and  defeated;  weapons  selected  and 
fired . 

HARDWARE  AND  SOFTWARE: 

Computer:  UNISYS  1180/84. 

Storage:  230K  (main);  140K  (extended). 

Peripherals :  Calcomp  plotter. 

Programming  Language:  SIMSCRIPT  II. 5. 

Documentation : 

•  CAA-D-86-2 ,  NUFAM  III  User's  Manual 

•  DTIC  AD0B1 1 31 73L 

SECURITY  CLASSIFICATION:  UNCLASSIFIED  without  data. 

GENERAL  DATA: 

Data  Base:  Data  base  prep:  1-6  weeks  depending  on  number  of 
excursions,  etc. 

CPU  Time  Per  Cycle:  Two-hours  per  repetition;  20-hours  per 
excursion . 
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Data  Output  Analysis:  Currently  can  produce  up  to  30 
pre-defined  reports.  Post-processor  package  (NUFAM-GAP)  allows 
free-form  database  queries  and  graphic  displays. 

Frequency  of  Use:  Support  in  1  to  5  studies/year. 

Users :  U.S.  Army  Concepts  Analysis  Agency. 

Comments :  None . 
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TITLE:  OPALS 


DATE  IMPLEMENTED:  1990. 


MODEL  TYPE :  Training  and  Education. 

PROPONENT :  Australian  Army  War  Game  Centre. 

POINT  OF  CONTACT:  Project  Leader  AWGC  62-2-9604411. 

PURPOSE: 

Analytical:  Yes. 

1 .  Research  &  Evaluation 

a.  Weapons  Systems 

Systems  Development? 

Systems  Effectiveness? 

b.  Force  Capability  and  Requirements 

Courses  of  Action  Assessment? 

Mix? 

Effectiveness? 

Resource  Planning 

c .  Combat  Development 

Current  or  New  Doctrine?  To  be  developed 

Competing  Strategies?  To  be  developed 

Policy  Study?  To  be  developed 

2.  Operation  Support  Tool  (Decision  Aid) 

a.  Skills  Development 

Team?  Yes 

Individual?  Yes 

b.  Exercise  Driver 

Field  Training  Exercise  Driver? 

Command  Post  Exercise  Driver? 

Individual  Exercise  Driver? 

DESCRIPTION: 

Domain:  Land. 

Span :  Regional. 

Environment :  Day  or  night  all  weather. 

Force  Composition:  Joint  and  combined  forces  (Blue  and  Red). 


No 

Yes 

No 


Scope  of  Conflict 


Conventional  warfare. 


Mission  Area:  All  conventional  missions  using  conventional 
weapons . 


172 


Level  of  Detail  of  Process  and  Entities: 

Entity :  Brigade  up  to  Corp. 

Process :  Attrition,  generation  of  casualties  (battle  and  non 

battle),  movement,  consumption  of  all  classes  of  supply,  repair 
and  recovery,  resupply,  casualty  treatment  and  evacuation, 
ammunition  and  fuel  usage. 


CONSTRUCTION : 

Human  Participation: 

(1)  Required: 

(a)  For  Decisions?  Yes 

(b)  For  Process?  No 

(c)  For  Both? 

(2)  Not  Required: 

(a)  Interruptable? 

(b)  Scheduled  Changes? 

(c)  Not  permitted? 


Time  Processing: 

( 1 )  Dynamic : 

(a)  Time  Step?  Yes 

(b)  Event  Step?  Yes 

(c)  Closed  Form? 

(2)  Static: 

Treatment  of  Randomness : 

(1)  Stochastic: 

(a)  Direct  Computation?  Yes 

(b)  Monte  Carlo?  No 

(2)  Deterministic: 

(a)  Generate  a  value  as  a  function  of  an  expected 
value? 

(b)  Basically  Deterministic  (No  randomness)? 


Sidedness : 

(1  ) 
(2) 


(3) 


One-sided? 

Two-sided : 

(a)  Symmetric? 

(b)  Asymmetric 

One  side  non-reactive? 

Both  sides  reactive?  Yes 

Greater  than  two-sided: 

(a)  Symmetric? 

(b)  Asymmetric 

One  or  more  side  non-reactive? 

All  sides  reactive? 


LIMITATIONS :  Simulation  of  naval  and  air  effects,  limited  to 

direct  effects  on  land  battle.  Resolution  in  simulating  low 
level  conflicts. 


PLANNED  IMPROVEMENTS /MODIFICATIONS :  Provision  of  video  map 
representation.  Enhanced  screen  presentation.  More  stations, 
improved  LANs,  multi-processing,  analytical  capability. 

INPUT :  Scenario,  weapon  characteristics,  operation  orders/plans, 

administration  orders/plans,  road  networks,  consumption  rates. 
Logistic  functional  characteristics. 

OUTPUT :  Printed  reports  detailing  unit  status,  staff  tables, 
logistic  reports  and  returns. 


HARDWARE  AND  SOFTWARE: 

computer  (OS):  IBM  PC  AT  MS  DOS  3.2;  VAX  VMS 
Storage :  Not  assessed  for  VAX. 

Peripherals :  Printers 

Programming  Language: 

Documentation :  Draft. 


and  a  plotter. 
Pascal . 


SECURITY  CLASSIFICATION:  Restricted. 
GENERAL  DATA: 

Data  Base:  Unknown  at  this  stage. 
CPU  Time  Per  Cycle:  Not  applicable. 


Data  Output  Analysis;  Not  applicable. 

Freguencv  of  Uses:  Expected  2  times  per  year  (initially). 

Users :  Command  and  Staff  College,  Command  Headquarters. 

Comments :  Release  date  2nd  quarter  1990.  Provides  both  real 

and  accelerated  time  play. 
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TITLE :  Optimum  Supply  and  Maintenance  Model  (OSAMM) 

DATE  IMPLEMENTED:  Original  release  -  1983;  release  2.0  -  1987. 
MODEL  TYPE :  Analysis. 

PROPONENT :  HQ  CECOM,  Attn:  AMSEL-PL-SA,  Fort  Monmouth,  NJ 

07703-5004 

POINT  OF  CONTACT:  Owen  Robatino,  AV  992-4381/(201)  532-5170. 

PURPOSE :  The  OSAMM  can  be  used  as  a  Research  &  Evaluation  Tool 

for  Logistic  Support  Analysis  (LSA).  It  performs  Level  of  Repair 
Analysis  (LORA)  on  new  and  existing  eguipment.  This  includes 
weapon  systems  as  well  as  support  eguipment.  The  OSAMM  can  deal 
with  a  system's  development  by  determining  the  impact  of  system 
design  on  logistics  support. 

It  should  be  noted  that  the  OSAMM  can  be  used  during  any 
phase  of  a  system's  life.  It  can  be  used  to  determine  the 
maintenance  concept  of  an  equipment  prior  to  fielding  or  to 
reconsider  the  maintenance  concept  of  an  equipment  after 
fielding.  It  determines  the  most  cost  effective  maintenance 
concept  and  initial  spares  placement  for  an  equipment,  subject  to 
an  availability  requirement. 

DESCRIPTION: 

Domain:  Land. 

Span :  Global. 

Environment :  N/A. 

Force  Composition:  N/A. 

Scope  of  Conflict:  N/A. 

Mission  Area:  N/A. 

Level  of  Detail  of  Processes  and  Entities: 

Entities :  Line  Replaceable  Units  (LRUs)  and  Shop  Replaceable 

Units  ( SRUs )  within  an  equipment.  Test  equipments  and 
repairmen  used  to  repair  the  equipment.  Maintenance  and  supply 
echelons  for  the  equipment. 

Processes :  Repair  of  end  item,  LRUs,  and  SRUs.  Supply  of 

LRUs,  SRUs,  and  piece  parts. 

CONSTRUCTION: 

Human  Participation:  Not  required. 

Time  Processing:  Static. 
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Treatment  of  Randomness :  Deterministic,  generating  values  as  a 
function  of  expected  values. 

Sidedness :  N/A. 

LIMITATIONS :  OSAMM  is  not  a  Wargaming  or  Simulation  model. 

PLANNED  IMPROVEMENTS /MODIFICATIONS :  Being  determined  by  U.S. 

Army  Materiel  Command,  Materiel  Readiness  Support  Activity 
( MRSA )  . 

INPUT :  LRU/SRU  breakdown,  logistic  structure.  Reliability  and 

Maintainability  (ELAM)  data,  inventory  cost  parameters,  Order-Ship 
Times  (OSTs),  Turnaround  Times  (TATs),  operational  availability 
target . 

OUTPUTS :  Repair  level  decisions,  spares  requirements,  test 

equipment  and  repairmen  requirements,  costs,  operational 
availability . 

HARDWARE  AND  SOFTWARE: 

Computer:  Control  Data  Corp  (CDC)  Network  Operating  System 

( NOS )  . 

Storage :  Unknown . 

Peripherals :  Terminal,  line  printer. 

Programming  Language :  FORTRAN  . 

Documentation :  OSAMM  Release  2.0  User's  Guide  -  DTIC  AD 

A1 87675;  OSAMM  Technical  Documentation  -  DTIC  AD  B1 15385. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED. 

GENERAL  DATA: 

Data  Base:  Depends  on  the  user's  knowledge  of  LSA,  OSAMM  and 
the  equipment  being  modeled. 

CPU  Time  per  Cycle:  Depends  on  the  complexity  of  the  equipment 
being  modeled. 

Data  Output  Analysis:  Depends  on  the  user's  knowledge  of 
OSAMM. 

Freguencv  of  Use:  Varies  by  activity,  but  is  used  at  least 
several  times  per  year  by  those  listed  below. 

Users:  CECOM,  AMCCOM,  AMSAA,  MRSA. 

Comment; :  OSAMM  uses  algorithms  of  the  Selected  Essential-Item 

Stockage  for  Availability  Method  (SESAME)  model,  which  is  the 
standard  Army  model  for  calculating  initial  sparing  quantities 
subject  to  an  availability  requirement. 
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DATE  IMPLEMENTED:  11/01/89 


TITLE:  PANIHER 

MODEL  TYPE:  Training  and  Education 

PROPONENT:  U.S.  Army  Combined  Arms  Command  -  Training,  ATTN:  ATZL-CTS 
Ft.  Leavenworth,  KS  66027 

POINT  OF  CONTACT:  MAJ  de  la  Pena,  MAJ  Velez,  CPT  Kbcne  AV  552-3189/3395 
ATTN:  ATZL-CTS-BB,  U.S.  Army  Combined  Arms  Command  -  Training 

PURPOSE:  Training  and  Education.  Panther  is  used  to  train  commanders  and 
staffs  on  staff  coordination  in  a  Low- Intensity  Conflict  (LIC)  environment. 

DESCRIPTION: 

Domain:  Land,  air  and  rivers. 

Span:  Local,  tactical  level. 

Environment:  Any  terrain,  weather,  time  or  day. 

Force  Composition:  Joint,  combined  at  tactical  level. 

Scope  of  Ccnclict:  LIC. 

Mission  Area:  Panther  focuses  on  the  nan-lethal  aspects  of  LIC  but 
also  models  direct  and  indirect  fire,  TACAIR,  aviation  and  air  defense. 

Level  of  Detail  of  Processes  and  Entities:  Panther  models  down  to 
individual  soldier,  individual  aircraft  or  piece  of  equipment.  In  a 
combat  engagement,  model  will  deplete  units  by  equipment,  munitions  and 
personnel  (WIA,  KIA,  MIA;  if  wounded  in  action  describes  wounds) .  Model 
processes  all  civil  affairs,  PSYOPS,  ccmbat  actions  by  zones.  This 
provides  the  basis  for  changes  in  popular  support  of  the  legitimate 
government  forces. 

Human  Participation:  Required,  waits  for  decisions. 

Time  Processing:  Dynamic. 

Treatment  of  Randomness:  Stochastic;  Monte  Carlo. 

Sidedness:  Two-sided,  asymmetrical. 

LIMITATIONS :  Boardgame  requires  maps  blown  up  to  1:6,  250  and  12,500 
scale.  Controllers  determine  CA/PSOPS  activities.  Requires  about  1  day 
to  install  data  base. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  Write  program  in  Spanish. 

Write  Battle  Board  Worksheet  in  such  a  way  that  one  worksheet  produces  one 
output.  Modify  software  to  make  system  more  user  friendly. 

INPUT: 

Scenario,  OPORD,  order  of  battle. 


OUTPUT: 

Computer  printouts. 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS):  IBM  XT/AT  MS  DOS 
STORAGE:  10  MB 

PERIPHERALS:  High  Speed  Printer 
PROGRAMMING  LANGUAGE:  Turbo  Pascal  5.5. 

DOCUMENTATION :  Basic  Rules,  How  to  Train  Manual  and  Technical  Guide. 
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SECURITY  CLASSIFICATION:  UNCLASSIFIED 


GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE:  1  day. 

CPU  TIME  PER  CYCLE:  Unknown 

DATA  OUTPUT  ANALYSIS:  N/A 

FREQUENCY  OF  USE:  As  often  as  desired. 

USERS:  U.S.  Army  tactical  units,  Latin  American  CGSC  and  AOC 
equivalent  schools. 


TITLE:  PROCA  DATE  IMPLEMENTED:  1989-90. 

MODEL  TYPE:  Analysis,  possibly  Training  &  Education. 

PROPONENT :  Operational  Research  and  Analysis  Establishment, 

Directorate  of  Land  Operational  Research. 

POINT  OF  CONTACT:  Daniel  U.  Thibault,  (613)  995-8080. 

PURPOSE :  Analysis  role:  Weapon  Systems  Effectiveness  Research  & 

Evaluation  Tool  Training  &  Education  role:  Seminar  Exercise 
Driver  Proca  is  designed  to  integrate  detailed  minefield 
breaching  assessment  into  the  Janus  computer  wargame .  It  is  a 
controller  tool,  the  Janus-Proca  interface  being  entirely  human. 
Proca  supplies  an  accurate  simulation  of  the  minefield  breaching 
per  se,  while  Janus  supplies  the  accurate  simulation  of  the 
simultaneous  direct  and  indirect  fire  battle.  Although  not 
designed  to  run  alone,  Proca  could  become  the  core  of  a  full 
scale  stand  alone  minefield  breaching  training  simulation; 
interest  has  already  been  expressed  by  developers  for  that 
particular  purpose. 

DESCRIPTION: 

Domain :  Land. 

Span :  Local. 

Environment :  Minefield  only.  Proca  can  handle  several 

minefields  at  once,  each  having  its  own  reference  frame.  Ground 
relief  and  features  are  not  modelled. 

Force  Composition:  Breaching  column  blue  or  red. 

Scope  of  Conflict:  Mines  and  Countermeasures  only. 

Mission  Area:  Minefield  breaching  only. 

Level  of  Detail  of  Processes  and  Entities: 

Entities :  Tank  sub-parts,  countermeasure  sub-parts, 

individual  mines. 

Processes :  Explosive  Breaching,  Mechanical  Breaching, 

Detection,  Scatterable  Mine  Delivery  All  processes  are 
time- independent  transformations  except  for  Mechanical 
Breaching.  In  the  latter,  a  described  breaching  column  of 
vehicles  encounters  mines  in  its  path  in  time  sequence  until 
the  breach  is  completed  or  a  vehicle  suffers  a  casualty. 

CONSTRUCTION: 

Human  Participation:  Required  for  Decisions  (The  simulation 
stops  until  the  player  inputs  a  new  command) . 
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Time  Processing:  Mechanical  Breaching  is  dynamic, 
event-driven;  all  other  processes  are  "instantaneous"  data  base 
transformations . 

Treatment  of  Randomness :  Stochastic,  Monte  Carlo. 

Sidedness :  Two-sided,  Asymmetric,  Both  Reactive.  The 

defending  player  can  only  react  with  the  addition  of  Scatterable 
Mines  in  between  breaching  player  actions. 

LIMITATIONS :  This  software  package  was  designed  as  a 

controller-level  "patch"  of  Janus  4.05.  It  could  also  be  used  as 
a  stand  alone  minefield  breaching  simulator  but  would  then  be 
somewhat  awkward  in  its  interface. 

PLANNED  IMPROVEMENTS /MODIFICATIONS :  Plans  for  its  integration 
into  a  full-blown  minefield  breaching  simulator  are  being 
discussed.  It  might  also  serve  as  a  basis  for  a  new  Janus 
minefield  module.  Finally,  there  is  a  remote  possibility  of  it 
being  developed  into  a  batch  processor  for  minefield, 
countermeasure,  and  tactic  effectiveness  assessment. 

INPUT :  Mine,  Countermeasure,  and  Vehicle  engineering 

characteristics.  Minefields  are  laid  out  using  a  companion 
software.  The  user  interface  is  textual,  menu-driven. 

OUTPUT;  Printout  of  event  log,  detailing  each  event  and  its 
outcome . 

HARDWARE  AND  SOFTWARE: 

Computer :  VAX/ VMS. 

Storage :  About  300k  of  source  code.  64k  of  executables. 

Master  data  file  around  10k,  most  minefields  data  files  are  in 
the  1 0  to  20k  range. 

Peripherals :  One  VT100  terminal  required.  Printer  currently 

hardwired  into  the  code. 

Programming  Language:  Pascal. 

Documentation :  DLOR  Staff  Notes  90/1,  90/2,  and  90/10. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED,  but  data  base  may  be 
classified . 

GENERAL  DATA: 

Data  Base:  Depends  on  accessibility. 

CPU  Time  per  Cycle:  Very  little;  simulation  is  interactive. 
Data  Output  Analysis:  Inserted  into  Janus  event  log. 

Freguencv  of  Use:  Iron  Dragon  wargame  series. 
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Users ;  DLOR.  Interest  has  been  expressed  by  various  other 
Janus  users  (USA,  UK,  Australia). 
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TITLE :  Small  Force  Weapons  and  Tactics  Evaluation  Model  -  SWATEM 

DATE  IMPLEMENTED:  1987. 


PROPONENT :  U.S.  Army  Ballistic  Research  Laboratory,  Aberdeen 

Proving  Ground,  MD  21005-5066. 

POINT  OF  CONTACT:  Dr.  Joseph  Wald,  DSN  298-9077/(301)278-9077. 

PURPOSE:  SWATEM  is  a  heterogeneous,  few-on-few  model  that 

simulates  a  battle  between  two  small  groups  of  opposing  forces. 
The  characteristics  of  the  weapons  (including  both  hardware  and 
tactics)  are  defined  by  user.  While  SWATEM  was  designed  to 
investigate  conflicts  between  air  defense  systems  and  hovering 
helicopters,  full  participation  on  both  sides  of  armored  vehicles 
and  hovering  helicopters  is  possible. 

DESCRIPTION: 

Domain :  Land  and  air. 

Span :  Local  battle. 

Environment :  Terrain  to  mask  helicopters  and  defilade  ground 

vehicles . 

Force  Composition:  Any  small  mix  of  hovering  helicopters  and 
ground  vehicles. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Ground  battle  and  air  defense. 

Level  of  Detail  of  Processes  and  Entities:  SWATEM  simulates  a 
battle  between  two  small  groups  of  opposing  forces.  Each  side 
may  have  up  to  10  individual  "game  pieces"  partitioned  into  at 
most  4  distinct  "weapon  classes".  The  definition  of  a  weapon 
class  includes  not  only  a  physical  description  of  the  weapon  and 
its  capabilities,  but  also  a  description  of  the  tactics  that  the 
weapon  will  employ  during  the  battle.  In  this  context,  the  term 
"tactics"  includes  such  features  as  exposure  time;  disengagement 
criteria;  weapon  selection;  under  what  conditions  to  close  with 
the  enemy,  hold  one's  position,  or  retreat;  and  the  many 
situations  in  which  a  decision  to  remask  (temporarily)  must  be 
made . 

CONSTRUCTION: 

Human  Participation:  Not  required. 

Time  Processing:  Event  step. 

Treatment  of  Randomness:  Stochastic,  Monte  Carlo. 
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Sidedness :  Two-sided,  symmetric. 

LIMITATIONS :  No  movement  of  systems  while  unmasked. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  SWATEM  will  be  replaced 
by  a  new  model  which  will  have  the  same  general  structure  as 
SWATEM,  but  will  have  many  enhancements,  both  in  weapon  class 
design  flexibility  and  in  the  modeling  of  tactics.  The  new  model 
will  be  less  slanted  toward  air  defense  with  more  detail  in  the 
modeling  of  the  ground  battle. 

INPUT :  For  each  system,  a  complete  physical  description  and 

tactical  profile.  The  type  and  amount  of  data  reguired  will  vary 
greatly,  depending  upon  the  types  of  systems  to  be  modeled. 

OUTPUT :  Damage  inflicted  by  each  side,  ordnance  expenditure 

statistics,  event  processing  histories,  graphics  -  battlefield 
"snapshots" . 

HARDWARE  AND  SOFTWARE: 

Computer:  CRAY  X-MP,  CRAY  II. 

Storage :  Approximately  500,000  words  on  a  CRAY  II  are 

sufficient  to  load  and  run  the  program. 

Peripherals :  Input  device,  printer,  graphics. 

Programming  Language:  FORTRAN  77. 

Documentation :  AMSAA  TR  437,  The  Small-Force  Weapons  and 

TActics  Evaluation  Model  (SWATEM),  March  1988  AD  B12142.  BRL- 
TR03060,  SWATEM:  Input  Guide,  December,  1989. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED. 

GENERAL  DATA: 

Data  Base:  A  few  hrs  to  a  week. 

CPU  Time  per  Cycle:  A  few  seconds  to  30  minutes  for  100  MC 
replications  on  CRAY  X-MP. 

Data  Output  Analysis:  A  few  minutes  to  an  hour. 
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DATE  IMPLEMENTED:  09/01/80 


TITLE:  Tactical  Simulator  (TACSIM) 

MODEL  TYPE:  Training  and  Education. 

PROPONENT:  Joint  Tactical  Fusion  Program  Management  Office  ( JTFPMD) , 
Mclean,  VA.  TRADOC  Proponent:  CAC-T,  Ft  Leavenworth,  KS 

POINT  OF  CONTACT:  Edward  N.  Sowell,  HQ  TEXCCM  ATTN:  ATCT-BA-SDM,  FT  Hood 
TX  76544  AV  738-9517;  TRADOC  POC:  MAJ  Marion,  AV  552-3180,  ATZL-CTS 

PURPOSE:  To  provide  an  interactive  computer-based  simulation  to  support 
intelligence  and  electronic  warfare  (IEW)  system  development  and  testing; 
ccrmand  post  training  exercises  (GPX);  and  evaluations  of  IEW  and  conmand, 
control  and  communications  (C3 )  functions.  It  supports  decisions,  corps 
and  echelons  above  corps  (EAC)  systems  evaluation,  training  and  the 
all-source  analysis  system/enemy  situation  correlation  element  (ASAS/ENSCE) 
program  development. 

DESCRIPTION: 

Domain:  Land  and  air. 

Span:  Local. 

Force  Composition:  OPPOR  equipment  signatures  detectable  by  sensors. 
Scope  of  Conflict:  Conventional  war. 

Mission  Areas:  Intelligence. 

CONSTRUCTION: 

Human  Participation:  Human  participation  required  for  decisions  and 
processes . 

Time  Processing:  Dynamic,  event  stepped. 

Treatment  of  Randomness:  Stochastic,  Monte  Carlo. 

Sidedness:  Two-sided,  asymmetric. 

LIMITATIONS :  The  resolution  of  the  sensor  modeling  is  not  sufficient 
for  sensor  trade-off  studies. 


INPUT: 

-  OPFOR  unit  observables ,  their  strengths  and  deployment. 

-  OPFOR  unit  locations  and  preplanned  movement. 

-  Operational  characteristics  of  the  sensors  and  tasking. 

-  Operational  environment  and  exercise  controllers. 

OUTPUT: 

The  primary  output  of  TACSIM  is  intelligence  reports  in  standardized 
format.  These  reports  are  of  the  quality  and  quantity  expected  of  the 
ccmnuni  cat  ions,  electronic  and  imagery  sensors  available  to  a  U.S. 
commander  in  wartime.  Special  reports  are  also  provided  to  assist 
simulator  operators  and  exercise  controllers. 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS):  VAX  11/785,  VAX  8250  or  VAX  8600.  VMS 

STORAGE:  16MB  internal  memory;  4  disk  drives  with  at  least  200  MB  each 

PERIPHERALS:  3  CRTs  and  one  printer. 

PROGRAMMING  LANGUAGE:  FORTRAN,  SALSIM  (FORTRAN  version  of  SIMSCRIPT) 
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DOCUMENTATION :  TACSIM  User's  Manual  for  Liaison  Officers  and  Exercise 
Controllers;  TACSIM  Software  Description,  Vol  I-III;  TACSIM  Operators 
Manual,  Vol  I-III;  Software  User /Operator  Manuals  (6). 

SECURITY  CLASS IFICATI CM :  UNCLASSIFIED. 

GENERAL  DATA  AND  TIME  REQUIREMENTS : 

DATABASE:  3  months 

CPU  TIME  PER  cycle:  Unknown 

DATA  OUTPUT  ANALYSIS:  N/A 

FREQUENCY  OF  USE:  Supports  training  of  division  and  corps  CPXs . 

COMMENTS:  TACSIM  is  normally  run  at  the  sensitive  ccmpartmented 
information  (SCI)  level  of  classification  which  limits  its  use  to  SCI 
facilities. 
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TITLE: 


TACVAR 


DEVELOPER:  IDA 

USER:  LA2 

PURPOSE :  To  assess  theatre  level  ground  combat  Letvean  NATO  and  VP  forces, 

to  provide  a  model  for  assessing  various  tactics  and  unit  dispersion 
philosophies  in  a  NBC  environment,  and  to  assess  the  contributions  and 
interactions  of  division  sized  combat  units,  along  with  tne  impact  ot 
air  units  and  nuclear  and  chemical  weapons,  on  the  outcome  of  the 
theatre  war. 

GENERAL  DESCRIPTION:  TACVAR  is  a  deterministic  simulation  of  battle  at 

Theatre  level.  It  comprises  five  main  submodels  -  ground  combat  model,  air 
combat  model,  target  acquisition  model,  nuclear  model  and  chemical  model. 
There  are  also  modules  to  update  force  status  and  to  model  resupply.  The  air 
and  ground  combat  models  operate  on  a  fixed  12-hour  cycle  while  the  TA, 
nuclear  and  chemical  models  have  a  variable  cycle  length  of  12-hours  or  less. 
Supplies  are  updated  every  72-96  hours.  Terrain  is  modelled  as  a  series  of 
sectors,  subdivided  into  battle  areas  as  in  the  LACM  (q.v.).  However,  unlike 
the  LACM,  forces  can  move  into  adjacent  sectors.  Forces  are  aggregated  into 
combat  divisions,  subdivided  into  company  sized  units  for  nuclear  and  chemical 
targetting.  The  numbers  of  personnel  and  weapons  in  each  unit  and  subunit  are 
recorded.  Separate  account  is  kept  of  chemical  and  nuclear  systems.  The  air 
model  represents  all  aspects  of  the  ai».  campaign,  including  close  air  support, 
interdiction,  counter  air,  air  defence,  escort,  defence  suppression  and  recce 
sorties.  Forward  airbases  are  located  within  battle  areas  and  may  be  overrun, 
ot  attacked  by  nuclear  or  chemical  weapons.  A  communications  zone  is  played 
for  each  side,  and  as  well  as  containing  rear  airbases,  provides  for  combat 
units,  tactical  aircraft,  supplies  and  replacement  weapons  and  personnel 
arriving  in  theatre.  The  target  acquisition  model  represents  fixed  and  mobile 
stand-off  sensors  and  penetrating  sensors,  which  may  be  associated  with 

divisions  or  with  geographical  areas.  Data  is  held  on  civilian  population 

dens i t ies . 

COMPUTER  STATUS:  Available  on  VAX 

DOCUMENTATION:  VSEG  Report  275  -  Vol  I  General  Description:  Vol  II  detailed 

description.  DOAE  Library  Acc  No  57411/2. 

COMMENT:  TACVAR  has  not  yet  been  used  in  a  DOAE  Study.  It  requires  a  large 

database,  and  DOAE  has  an  unclassified  test  version. 
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TITLE:  Target  Acquisition  Fire  Support  Model  -  TAFSM 

DATE  IMPLEMENTED:  Circa  1983. 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.  S.  Army  Field  Artillery  School,  Fort  Sill,  OK 

73503-5600,  U.  S.  Army  Materiel  Systems  Analysis  Activity, 
Aberdeen  Proving  Ground,  MD  21005-5071  . 

POINT  OF  CONTACT:  U.  S.  Army  Materiel  Systems  Analysis  Activity 
Attn:  AMXSY-GS  (L.  Blankenbiller ) ,  Aberdeen  Proving  Ground,  MD 
21005-5071,  DSN  298-5047/(301)  278-5047. 

PURPOSE :  TAFSM  is  a  damage  assessment/weapons  effectiveness 

model  used  primarily  as  a  Research  and  Evaluation  Tool.  It  is 
designed  to  evaluate  competing  artillery  force  structures  and 
operational  concepts  as  well  as  the  effects  of  weapon  systems 
against  various  target  types. 

DESCRIPTION: 

Domain:  Land  and  air. 

Span :  European  theater;  division  sized. 

Environment :  Statistical  terrain  is  used;  database  reflects 

terrain  interactions  ( line-of-sight ) ,  open/woods  environment, 
time  of  day  (day/night) . 

Force  Composition:  Combined  forces,  Blue  and  Red. 

Scope  of  Conflict:  Conventional  weapons. 

Mission  Area:  Primarily  indirect  fire  artillery  with  modular 
direct  fire  ground  game. 

Level  of  Detail  of  Processes  and  Entities:  Unit  resolution  is 
a  function  of  range  from  the  FLOT  anduser-directed  inputs. 
Maneuver  units  are  usually  at  platoon  level;  fire  units  at 
platoon  or  section  level.  Movement,  target  acquisition, 
communications  and  mission  processing  activities  are  explicitly 
played  at  the  lowest  level  defined  by  the  user.  Damage  is 
assessed  against  each  individual  target  element.  Attributes  for 
weapon  systems,  ammunition  types,  fire  direction  centers  and 
sensors  define  the  systems'  capabilities  and  performance  measures 
used  by  subroutines  which  model  the  systems'  operational 
functions . 

CONSTRUCTION: 

Human  Participation:  Not  permitted. 
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Time  Processing:  Event  sequenced,  time  stepped  using  dynamic 
24/^8  hour  scenario. 

Treatment  of  Randomness:  Indirect  fire  kills  are  assessed 
stochastically,  with  Monte  Carlo  determination  of  result.  The 
direct  fire  ground  game  uses  a  stochastic  Lanchester  attrition 
model . 

Sidedness :  Two-sided,  symmetric. 

LIMITATIONS :  Fixed  movement  paths,  dirty  battlefield  not  played 

explicitly,  Red  artillery  decision  rules  same  as  Blue,  large 
threat  data  scenario  requirements,  e. '.tensive  scenario  development 
effort  required. 

PLANNED  IMPROVEMENTS /MODIFICATIONS :  Updated  scenario.  Refined 
direct  fire  ground  game.  Joint  task  force  missions  added. 

INPUT :  Unit  locations  and  movement  schedules.  Weapon  system  and 

sensor  characteristics.  Munition  characteristics. 

Communications  network.  Force  structure. 

OUTPUT :  Tabular  data:  measures  of  effectiveness  -  no.  systems 

destroyed,  no.  of  personnel  killed,  force  attrition;  measures  of 
performance-  fire  missions  requested/fired,  sensor  reports, 
ammunition  expenditures,  effects  per  round  type  and  target 
element,  tube  failures  and  attrition,  other  items  from  fire 
direction  centers,  communications  system  and  resupply. 

HARDWARE  AND  SOFTWARE: 

Computer :  Digital  VAX/VMS  11/785. 

Storage :  220K  Bytes. 

Peripherals :  Line  printer,  magnetic  disks  and/or  tape  drives. 

Programming  Language :  FORTRAN  77  dialect  XFOR. 

Documentation :  User  and  programmer  manual.  Draft 

documentation  for  the  direct  fire  ground  game  module. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED  without  database  and/or 
scenario . 

GENERAL  DATA: 

Data  Base:  Time  to  make  database  updates  and  set  up  inputs 
might  run  as  much  as  two  to  four  weeks. 

CPU  time  per  Cycle:  Approximately  8-10  hours  with  minimum 
acceptable  replications  and  a  24  hour  scenario. 

Data  Output  Analysis:  Typically  a  week  or  more  is  required. 

Freguency  of  Use:  Varies  extensively  by  organization,  but  is 
used  at  least  several  times  per  year. 
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Users:  Directorate  of  Combat  Developments,  U.  S.  Army  Field 
Artillery  School  and  Ground  Warfare  Division,  U.  S.  Army  Materiel 
Systems  Analysis  Activity. 

Comments :  None. 

RELEASABILITY :  Program  code  is  releasable.  Some  input  data  are 

classified  SECRET  NOFORN  and  therefore  not  releasable. 
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TITLE:  TERRA  AUSTRALIS 


DATE  IMPLEMENTED:  1985. 


MODEL  TYPE :  Training  and  Education. 

PROPONENT:  Australian  Army  War  Game  Centre. 

POINT  OF  CONTACT:  Project  Leader  AWGC  62-2-9604411. 

PURPOSE: 

Analytical : 

1 .  Research  &  Evaluation 

a.  Weapons  Systems 

Systems  Development? 

Systems  Effectiveness? 

b.  Force  Capctbiiity  and  Requirements 

Courses  of  Action  Assessment? 

Mix? 

Effectiveness? 

Resource  Planning 

c .  Combat  Development 

Current  or  New  Doctrine? 

Competing  Strategies? 

Policy  Study? 

2.  Operation  Support  Tool  (Decision  Aid) 

a.  Skills  Development 

Team?  Yes 

Individual?  No 

b.  Exercise  Driver 

Field  Training  Exercise  Driver? 

Command  Post  Exercise  Driver? 

Individual  Exercise  Driver? 

DESCRIPTION: 

Domain :  Land. 

Span :  Theatre. 

Environment :  Day  or  night.  All  weather. 

Force  Composition:  Joint  and  combined  forces.  (Red  and 
Blue )  . 

Scope  of  Conflict:  Conventional  warfare. 

Mission  Area:  All  conventional  missions. 


No 

Yes 

No 
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Level  of  Detail  of  Process  and  Entities: 

Entity :  Brigade  to  Corp. 

Process :  Attrition  of  personnel  and  equipment,  generation  cf 

casualties  (both  battle  and  non  battle),  consumption  of  classes 
1,  3,  5  and  others,  repair  and  recovery,  resupply,  casualty 
treatment  and  evacuation,  transport  and  movement. 

CONSTRUCTION: 

Human  Participation: 

( 1 )  Required : 

(a)  For  Decisions?  Yes 

(b)  For  Process?  No 

(c)  For  Both? 

(2)  Not  Required: 

(a)  Interruptable? 

(b)  Scheduled  Changes? 

(c)  Not  permitted? 

Time  Processing: 

( 1 )  Dynamic : 

(a)  Time  Step?  Yes.  24  hour  game  turn  to  6  hours 

real  time. 

(b)  Event  Step? 

(c)  Closed  Form? 

(2)  Static: 


Treatment  of  Randomness: 

(1)  Stochastic: 

(a)  Direct  Computation?  Yes 

(b)  Monte  Carlo?  No 

(2)  Deterministic: 

(a)  Generate  a  value  as  a  function  of  an  expected 
value? 

(b)  Basically  Deterministic  (No  randomness)? 

Sidedness : 

( 1 )  One-sided? 

(2)  Two-sided: 

(a)  Symmetric? 

(b)  Asymmetric 

One  side  non-reactive? 

Both  sides  reactive?  Yes 

(3)  Greater  than  two-sided: 

(a)  Symmetric? 

(b)  Asymmetric 

One  or  more  side  non-reactive? 

All  sides  reactive? 


LIMITATIONS :  Only  limited  Naval  and  Air  effects  are  modelled. 


PLANNED  IMPROVEMENTS/MODIFICATIONS :  Planned  replacement  by 
OPALS . 
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INPUT:  Weapons,  attrition  tables,  characteristics  of  units,  road 

networks,  consumption  tables,  Logistic  functional 
characteristics . 


OUTPUT :  Printed  reports  of  staff  tables,  attrition  logistics 
holdings . 


HARDWARE  AND  SOFTWARE: 

Computer  ( OS ) :  IBM  PC/AT  with  PC  Network; MS  DOS 
Storage :  8Mb  disk  for  total  system.  1.5Mb  per 
Peripherals :  132  column  printers. 


Documentation:  Draft 

SECURITY  CLASSIFICATION 

:  Restricted. 

GENERAL  DATA: 

Data  Base:  2  weeks. 

CPU  Time  Per  Cycle: 

Not  applicable. 

Data  Output  Analysis: 

None  . 

Freauencv  of  Uses:  1 

per  year . 

3.2. 

station . 


Users:  Command  and  General  Staff  Course. 
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TITLE :  Test  Program  Set  Cost  Effectiveness  Evaluation 

Model  -  TPS  CEEM 

MODEL  TYPE:  Analysis. 

PROPONENT:  HQ  CECOM,  Attn:  AMSEL-PL-SA,  Fort  Monmouth,  NJ 

07703-5000 

POINT  OF  CONTACT:  Owen  Robatino,  AV  992-4381 /( 20 i )  532-3646. 

PURPOSE :  TPS  CEEM  is  used  as  a  research  &  evaluation  tool  for 

determining  the  economic  feasibility  of  utilizing  TPSs  for  the 
maintenance  of  circuit  card  assemblies  (CCAs). 

DESCRIPTION: 

Domain :  Land. 

Span :  Global. 

Environment :  N / A . 

Force  Composition :  N / A . 

Scope  of  Conflict:  N/A. 

Mission  Area:  N/A. 

Level  of  Detail  of  Processes  and  Entities : 

Enti ties :  Line  Replaceable  Units  (LRUs)  and  Shop  Replaceable 
Units  ( SRUs )  within  an  equipment.  Test  equipments  and 
repairmen  used  to  repair  the  equipment.  Maintenance  and  supply 
echelons  for  the  equipment. 

Processes :  The  model  evaluates  six  maintenance  alternatives, 

three  of  which  involve  the  development  and  usage  of  a  TPS.  The 
model  estimates  the  nonrecurring  costs  of  TPS  development, 
documentation,  and  Interconnecting  Devices  (ICDs);  TPS 
maintenance  costs  over  the  end  item  life;  and  other  applicable 
costs . 

CONSTRUCTION: 

Human  Participation:  Not  required. 

Time  Processing:  Static. 

Treatment  of  Randumness :  Deterministic;  generates  values  as  a 
function  of- expected  value  process. 

Sidedness :  N/A. 

LIMITATION :  User's  manual  has  not  been  developed. 
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PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  A  user's  manual  will  be 
developed . 


INPUT: 

End  Item  Input  File:  Data  unique  to  the  end  item  under 
consideration  and  data  on  each  CCA  including  cost  of  TPS 
development.  This  file  is  created  by  the  user. 

Factors  Input  File:  Logistics  and  cost  factors  such  as  support 
costs  and  percentages  as  well  as  times  associated  with 
maintenance  and  supply.  Default  values  for  this  file  are  under 
development.  The  user  can  modify  and  default  values  to  suit  the 
end  item  under  consideration. 

OUTPUT: 

Listing  of  input  data. 

Table  of  estimated  costs  of  each  maintenance  alternatives  for 
each  CCA  with  an  indicator  highlighting  the  lowest  cost 
alternative . 

CCA  rank  ordered  based  on  estimated  TPS  costs  effectiveness. 

CCA  rank  ordered  based  on  highest  expected  failures  over  life 
cycle . 

HARDWARE  AND  SOFTWARE: 

Computer :  PC  Compatible. 

Storage:  100K  bytes  for  executable  code. 

Peripherals :  Monitor,  printer. 

Programming  Language:  FORTRAN  77 

Documentation :  Test  Program  Set  Cost  Effectiveness  Evaluation 

Model  (TPS  CEEM )  General  Description,  Jan  1988,  USA  CECOM,  P&O 
Directorate,  Systems  Analysis  Division. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED. 

GENERAL  DATA: 

Data  Base:  n/a. 

CPU  Time  per  Cycle:  Depends  on  the  number  of  CCA's  being 
analyzed . 

Frequency  of  Use:  Has  been  used  on  four  CECOM  programs  and  it 
will  be  used  on  many  more  CECOM  programs. 

Users:  Joint  STARS,  SINCGARS,  AN/TMQ-31  and  DGM  programs. 

Comments :  The  model  is  structured  to  allow  the  user  to 

interactively  perform  sensitivity  analysis  on  five  factors. 

Releasability :  Releasable  to  U  S .  Government  only. 


TITLE  TEWTORIAL 


DATE  IMPLEMENTED:  1982. 


MODEL  TYPE:  Analysis. 

PROPONENT :  BGWG  Section,  CA4  Division,  RARDE,  Fort  Halstead, 

Kent,  England,  U.K. 

POINT  OF  CONTACT:  I.  S.  Gardner,  CA4 ,  RARDE,  Fort  Halstead, 

Kent,  U.K.,  0959-32222,  ext  2444. 

PURPOSE:  The  game  is  a  research  and  evaluation  tool,  dealing 

primarily  with  weapon  systems  development  and  effectiveness.  It 
can  also  be  used  to  assess  force  capability  and  requirements, 
dealing  with  courses  of  action,  mix,  and  effectiveness. 

DESCRIPTION: 

Domain :  Land. 

Span :  Local. 

Environment :  A  1:20,000  map. 

Force  Composition:  Up  to  Regimental  level. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Any  conventional  missions  within  the  domain. 

Level  of  Detail  of  Processes  and  Entities:  The  lowest  entities 
modelled  are  fire  teams  and  individual  vehicles,  though  most 
units  are  of  platoon  size.  Attrition,  movement  and  target 
acquisition  are  modelled  for  each  entity. 

CONSTRUCTION: 

Human  Participation:  Required  for  decisions  and  processes. 

Time  Processing:  Processing  is  dynamic,  the  model  uses  time 
stepping . 

Treatment  of  Randomness:  The  model  is  stochastic,  it  uses  the 
Monte  Carlo  method. 

Sidedness :  The  model  is  two-sided  and  symmetric. 

LIMITATIONS :  Does  not  model  C3I,  close  combat  and  air/ground 

interactions  are  not  modelled  adequately.  The  model  is  only 
detailed  enough  to  investigate  gross  changes  in  weapon  systems, 
force  composition,  etc.. 

PLANNED  IMPROVEMENTS /MODIFICATIONS :  None. 
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INPUT:  System  and  weapon  characteristics  including  attrition 

data,  mobility  data  and  activity  timings. 

OUTPUT:  Records  of  all  direct  fire  and  indirect  fire  events  and 

mine  encounters  are  recorded  manually. 

HARDWARE  AND  SOFTWARE: 

Computer :  None. 

Storage :  None. 

Peripherals :  None. 

Programming  Language:  None. 

Documentation :  There  is  a  set  of  rules  and  data  tables. 

SECURITY  CLASSIFICATION:  UNCLASSIFIED,  data  classified  SECRET. 
GENERAL  DATA: 

Data  Base:  About  3  man  months  per  study. 

CPU  Time  per  Cycle:  None. 

Data  Output  Analysis:  Manual. 

Freguency  of  Use:  No  longer  in  regular  use. 

Users :  BGWG  section,  CA4  Division  in  response  to  requests  for 

studies  by  a  series  sponsor  from  within  the  MOD. 

Comments :  There  are  at  least  two  other  versions  of  this  model 

in  the  U.K. 
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TITLE :  TOW  Missile  System  Simulations  DATE  IMPLEMENTED :  1978. 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.S.  Army  Materiel  Systems  Analysis  Activity. 

POINT  OF  CONTACT:  Director,  USAMSAA,  ATTN:  AMXSY-CS 
(MR.  A.  GORDON),  Aberdeen  Proving  Ground,  MD  21005-5071 
AV  298-6459/(301)  278-6459. 

PURPOSE :  A  set  of  research  and  evaluation  tools  used  during 

system  development  and  to  provide  item  level  performance  input  to 
force-on-force  models.  The  TOW  Missile  Systems  Simulations  are 
computerized,  analytical  models  that  simulate  the  in-flight 
performance  of  the  family  of  TOW  Missile  Systems.  These 
simulations  are  used  primarily  to  compute  the  accuracy  of  the  TOW 
Missile  Systems  using  gunner  aiming  error  and  target  motions  as 
input . 

DESCRIPTION :  The  TOW  simulations  include  6  degree-of-freedom 

equations  of  motion,  mathematical  models  of  the  guidance 
equations  and  uncertainties  associated  with  certain  parameters. 
Domain :  Land,  air. 

Span :  Individual. 

Environment :  None. 

Force  Composition:  Element. 

Scope  of  Conflict:  Any  involving  guided  anti-armor  weapons. 

Mission  Area:  Anti-armor. 

Level  of  Detail  of  Processes  and  Entities: 

Entity :  Individual  weapon  and  its  mount. 

Processes :  Probability  of  hit. 

CONSTRUCTION: 

Human  Participation:  Not  permitted. 

Time  Processing:  Static. 

Treatment  of  Randomness:  Stochastic,  Monte  Carlo. 

Sidedness :  One-sided. 

LIMITATIONS :  One-on-one,  no  obscuration. 
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PLANNED  IMPROVEMENTS /MODIFICATIONS :  Effort  is  underway  to  recode 
all  basic  TOW  simulations  in  a  Universal  TOW  Simulation  model, 
and  to  develop  a  family  of  TOW  IIB  models. 

INPUT :  Gunner  Aiming  Error;  Target  Velocity. 

OUTPUT :  User  selectable  including  means  and  standard  deviations 

of  the  missile's  position  as  a  function  of  time. 

HARDWARE  AND  SOFTWARE: 

Computer  (OS):  Cray  XMP  (UNIX). 

Storage  required:  32K. 

Peripherals :  None. 

Programming  Language :  FORTRAN . 

Documentation :  AMSAA  TR  293,  "Simulation  and  Analysis  of  the 

Training  Effectiveness  Analysis-TOW  (TEA-TOW)  Flight  Data," 
Patrick  E.  Corcoran,  April  1980. 

SECURITY  CLASSIFICATION:  (Model  without  data)  UNCLASSIFIED . 
GENERAL  DATA: 

Database :  Available  from  tests  and  separate  models;  about  one 

week  depending  on  scope. 

CPU  Time  per  Cycle:  5  seconds. 

Data  Output  Analysis:  A  few  hours. 
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DATE  IMPLEMENTED:  01/01/82 


TITLE:  Transportation  and  Supply  Activities  (TRANSACT) 

MODEL  TYPE:  Analysis 

PROPONENT:  TRADOC  Analysis  Ccrmand,  Ft  Lee  (TRAC-LEE) 

Fort  Lee,  VA  23801 

POINT  OF  CONTACT:  Bruce  E.  Lasswell,  P’7  587-1050,  Fort  Lee,  VA  23801 

PURPOSE:  To  furnish  information  on  how  supply  requests  may  be  satisfied 
under  constraints  of  load/unload  capability,  vehicle  availability, 
terminal /dock  availability,  network  and  enemy  attack. 

DESCRIPTION:  TRANSACT  is  a  physical  distribution  model  created  usiny  □«. 
MAWLOGS  Modeling  System.  It  can  be  run  either  stochastically  or 
deterministically.  Unit  requests  are  levied  cn  a  supply  system  which 
assigns  loading  assets  and  vehicles  to  ships  request  over  a  detailed 
network .  Vehicles  may  be  attacked  when  halted.  The  terminals,  supply 
points,  and  network  may  also  be  attacked. 

CONSTRUCTION: 

Human  Participation:  Not  required — scheduled  changes. 

Time  Processing:  Dynamic,  event-step. 

Treatment  of  Randomness:  Either  stochastic,  Monte  Carlo  or  basically 
deterministic  as  required  by  the  user. 

Sidedness :  One-sided . 

LIMITATIONS :  Data  set  can  be  extensive.  Not  directly  related  to  combat 
models. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  None. 

INPUT:  Weight  and  cube  of  items  to  be  moved,  supply  support  structure 
and  stockage  parameters/policy,  transportation  network  description,  supply 
request  schedule,  vehicle  characteristics  and  location,  scenario  such  as 
location  and  priority  of  units,  and  attack  schedule. 

OUTPUT:  Weight  and  cube  of  cargo  delivered  (also  number  of  items  by  item), 
items  requested,  network  and  vehicle  overloads,  average  and  peak  workloads 
for  each  link/ terminal,  queue  buildups  for  each  link/ terminal,  supply 
point  workloads  and  supply  status  by  node /class/ item,  dock  and  vehicle 
utilization,  BOH  at  supply  units  over  time,  vehicle  production  in  terms  of 
weight  and  distance,  attack  results. 

HARCWARE  AND  SOFTWARE: 

COMPUTER  (OS):  VAX  11/780,  SUN  4/280. 

STORAGE :  Variable . 

PERIPHERALS:  Printer  and  tape  drive. 

PROGRAMMING  LANGUAGE:  FORTRAN  77. 

DOCUMENTATION:  Users'  Guide  for  LOGATAK  II  (DLSIE  42543-MC), 

Programers '  Guide  for  LOGATAK  II. 

OTHER  COMMENTS:  TRANSACT  was  created  using  the  Models  of  the  Army 
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Worldwide  Logistics  System  (MAWLOGS) . 

SECURITY  CLASS IFICATICN :  UNCLASSIFIED. 

GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE:  N/A. 

CPU  TIME  PER  CYCTF :  Varies . 

DATA  OUTPUT  ANALYSIS:  Cue  to  three  weeks. 

FREQUENCY  OF  USE:  As  needed. 

USERS:  Proponent  and  U.S.  Army  Transportation  School. 

COMMENTS:  Government  agencies  can  obtain  TRANSACT  with  a  signed 
memorandum  of  agreement.  Government  contractors  with  a  valid  contract 
requiring  the  use  of  TRANSACT  can  also  obtain  the  model  with  the  approval 
of  the  TRAC  Commanding  General.  Inquiries  for  obtaining  the  model  and 
supporting  data  bases  should  be  addressed  to  TRAC -TOD,  Ft.  Leavenworth,  KS 
66027-5200  or  call  Av  552-5511  or  commercial  913-684-5511. 
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TITLE :  Transportation  Model  -  TRANSMO  Date  Implemented:  1979 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.S.  Army  Concepts  Analysis  Agency,  Attn: 

Mobilization  and  Deployment  Directorate,  8120  Woodmont  Avenue 
Bethesda ,  MD  20814-2797. 

POINT  OF  CONTACT:  Ms.  Vera  W.  Hayes,  (301)  295-1137/AV  295-1137 

PURPOSE :  TRANSMO  is  used  primarily  to  analyze  strategic 

deployment  issues  taken  in  the  context  of  the  Defense  Guidance 
Illustrative  Planning  Scenario.  It  specifically  simulates  the 
loading  of  cargo  on  inter- theater  lift  vehicles,  ultimately 
resulting  in  an  arrival  sequence  of  cargo  in  the  theater (s)  of 
operation . 

DESCRIPTION: 

Domain:  Sea  and  air. 

Span :  Accommodates  any  theater  or  theaters  depending  on  data 

base  input. 

Environment :  Availabilities,  loading  and  unloading  time  of 

inter-theater  lift  assets  are  represented  in  terms  of  hundredths 
of  an  hour.  Port  throughput  capacities  are  represented  by 
numbers  of  lift  assets  that  can  be  handled  at  any  given  time 
during  the  simulation. 

Force  Composition:  Movement  requirements  represent  all 
services,  with  particular  emphasis  on  Army  requirements  (data 
base  dependent). 

Scope  of  Conflict:  Generally  conventional  with  capability  to 
represent  chemical  degradation  of  ports. 

Mission  Area:  Generally  represents  sea  and  airlift 
requirements . 

Level  of  Detail  of  Processes  and  Entities:  Processes  on  an 
hourly  basis  for  aircraft  and  a  daily  basis  for  sealift.  Lift 
assets  are  represented  by  their  speed  and  capacity--short  tons 
for  airlift  and  short  tons,  square  feet,  and  measurements  tons 
for  sealift.  Movement  requirements,  which  represent  a  varied 
level  of  detail  from  a  division  to  a  UIC  or  an  aggregation  of 
resupply  or  ammunition  requirements,  are  displayed  by  their 
characteristics  (bulk,  over,  outsize  cargo  for  air  requirements 
and  short  tons,  square  feet,  and  measurement  tons  for  sealift 
requirements).  Attrition  is  based  on  an  expected  value;  if  sea 
or  air  assets  are  in  the  zone  of  hazard  during  the  period  in 
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which  attrition  is  begin  applied,  each  vessel  will  be  attrited  by 
the  expected  attrition  value  in  effect.  TRANSMO  can  be  viewed  as 
a  model  with  a  flexible  level  of  detail  ranging  from  low  to  high 
levels  of  resolution  depending  upon  the  input  data. 

CONSTRUCTION: 

Human  Participation:  None  required;  relies  on  scheduled 
changes . 

Time  Processing:  Dynamic,  time  and  event  step. 

Treatment  of  Randomness:  Sea  and  air  attrition  are 
deterministically  determined  based  on  expected  value  during  a 
time  period. 

Sidedness :  One-sided. 

LIMITATIONS :  No  specific  limitations. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  None . 

INPUT: 

•  Scenario  data  include 

••  lift  asset  availability  at  POEs 
• •  asset  capacities 
•  •  load  and  unload  times 
• •  distances  between  ports 
• •  pre-determined  attrition  rates 

•  Movement  requirements  include 
• •  availability  at  the  POE 

• •  latest  arrival  date  at  the  POD 

••  unit  of  measurements  expressed  in  terms  of  short  tons, 
square  feet,  and  measurement  tons 

OUTPUT:  Depends  on  the  level  of  detail  and  quality  of  the  input. 

Produces  printouts  of  movement  requirements;  attrition  associated 
with  each  requirement,  and  arrival  time  at  the  POD.  Many  other 
analyst  reports  are  available  for  review  to  determine  how  the 
deployment  was  conducted. 

HARDWARE  AND  SOFTWARE: 

Computer :  Originally  designed  to  run  on  the  UNISYS  1100/84. 

Primarily  executed  on  the  VAX  8600  with  VMS  operation  system. 
Storage:  80,000  blocks  (40  MB)  for  the  model  only. 

Peripherals :  Minimum  requirements:  one  printer,  one  VT100 

terminal,  and  one  400K  block  hard  disk. 

Language:  FORTRAN  77. 

Documentation :  User  manual  with  two  appendixes. 

SECURITY  CLASSIFICATION:  Unclassified,  but  data  bases  are 
generally  classified. 
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GENERAL  DATA: 

Date  Base:  Full  scenario  development  and  generation  of 
movements  requirements  require  approximately  two  man-months  of 
effort . 

CPU  Time  Per  Cycle:  Scenario  dependent,  but  normally  under  30 
minutes . 

Data  Output  Analysis:  Post-processor  aids  in  analysis  of 
outputs.  Analysis  is  generally  completed  within  three  weeks 
after  the  first  output  is  produced. 

Frequency  of  Use:  In  constant  use  to  support  USACAA  studies. 
The  model  is  run  more  than  100  times  per  year. 

Users :  USACAA. 

Comments :  Managed  by  the  USACAA  to  support  all  strategic 

deployment  studies  supporting  larger  efforts  (OMNIBUS,  SRA ,  PFCA, 
SCAN ,  and  MRFS )  changes  to  the  model  are  made  as  necessary  to 
support  model  improvement  or  when  analytical  needs  dictate. 
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DATE  IMPLEMEJTTED:  01/01/82 


TITLE:  Transportation  Network  Attack  Model  (TRANATAK) 

MODEL  TYPE:  Analysis 

PROPONENT:  TRADOC  Analysis  Ccrrmand,  Ft  Lee  (TRAC-LEE) 

ponrr  OF  CONTACT:  Bruce  E.  Lasswell,  AV  687-1050,  Ft  Lee,  VA  23801 

PURPOSE:  Tt>  furnish  information  cn  how  transportation  requests  may  be 
satisfied  under  constraints  of  load/unload  capability,  vehical  capability 
and  availability,  terminal/dock  availability,  network  and  enemy  attack. 

DESCRIPTION :  This  is  a  transportaticn-only  derivative  model  of  the 
MAWLOGS  modeling  system.  The  model  responds  to  scheduled  (push)  shipments 
over  a  explicit  network  using  discrete  vehicles.  Vehicles  are  loaded  by 
weight  and  cube.  Only  when  halted  may  vehicles  be  attacked. 


CONSTRUCTION: 

Human  Participation:  Not  required — scheduled  changes. 

Time  Processing:  Dynamic,  event-step. 

Treatment  of  Randomness:  Either  stochastic,  Monte  Carlo  or  basically 
deterministic  as  required  by  the  user. 

Sidedness:  One-sided. 

LIMITATIONS :  Data  set  can  be  extensive.  Not  directly  related  to  combat 
models . 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS :  None. 

INPUT:  Weight  and  cube  of  items  to  be  moved,  transportation  network 
description  (based  cn  other  model  ouputs  or  SCORES  scenario  data), 
transportation  request  schedule,  vehicle  characteristics  and  locations, 
scenario  such  as  location  and  priority  of  units,  and  attack  schedule. 

OUTPUT:  Weight  and  cube  of  cargo  delivered  (also  number  of  items  by 
item),  items  requested,  network  and  vehicle  overloads,  average  and  peak 
workloads  for  each  link/ terminal,  queue  buildups  for  each  link/ terminal, 
supply  point  workloads  and  supply  status  by  node/class/item,  dock  and 
vehicle  utilization,  vehicle  production  in  terms  of  weight  and  distance, 
at  results. 

HAREWARE  AND  SOFTWARE: 

COMPUTER  (OS):  VAX  11/780,  SUN  4/280. 

STORAGE :  Variable . 

PERIPHERALS:  Printer  and  tape  drive. 

PROGRAMMING  LANGUAGE:  FORTRAN  77. 

DOCUMENTATION:  User's  Guide  for  LOGATAK  II,  (DLSIE  42543-MC), 
Programers'  Guide  for  LOGATAK  II. 

UIUER  COMMENTS:  TRANATAK  was  created  using  the  Models  of  the  Army 
Worldwide  Logistics  System  (MAWLOGS). 

SECURITY  CLASSIFICATION :  UNCLASSIFIED. 
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GENERAL  DATA  AND  TIME  REQUIREMENTS: 


DATABASE:  N/A. 

CPU  TIME  PER  CYCLE :  Varies . 

DATA  OUTPUT  ANALYSIS:  Varies. 

FREQUENCY  OF  USE :  As  needed . 

USERS:  Proponent  and  U.S.  Army  Combined  Arms  Support  Command. 

COMMENTS:  Government  agencies  can  obtain  IRANATAK  with  a  signed 
memorandum  of  agreement.  Government  Contractors  with  a  valid  contract 
requiring  the  use  of  TRANATAK  can  also  obtain  the  model  with  the  approval 
of  the  TRAC  Commanding  General.  Inquiries  for  obtaining  the  model  and 
supporting  data  bases  should  be  addressed  to  TRAC-TOD,  Ft.  Leavenworth, 

KS  66027-5200  or  call  AV  552-5511  or  commercial  913-684-5511. 
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TITLE :  TRASANA  Aircraft  Reliability  and  Maintainability 

Simulation  -  TARMS  CAA  Version  II 

DATE  IMPLEMENTED:  1985.  Original  implementation  1978. 

MODEL  TYPE:  Analysis. 

PROPONENT:  TRASANA,  White  Sands  Missile  Range,  White  Sands,  New 

Mexico  88002-5502. 

POINTS  OF  CONTACT:  Mr.  A.  Gamble,  (AV)  258-1901,  Renee  Carlucci, 
Chief,  Modeling  Team,  U.S.  Army  CAA-FSC,  (301)  295-5292. 

PURPOSE :  TARMS  is  designed  to  provide  information  on  the 

operational  availability  of  aviation  elements  of  combat  forces 
based  on  losses  due  to  combat  damage,  system  failures,  and 
repair;  and  on  return  to  combat  based  on  times  to  repair, 
maintenance  manpower,  and  parts  supply. 

DESCRIPTION: 

Domain :  Land  and  air. 

Span :  Accommodates  from  company  to  theater  depending  on  the 

database . 

Environment :  Cartesian  plane;  night  and  day  operations,  peace 

and  war  time. 

Force  Composition:  Blue  Aircraft,  AVIM  and  AVUM  level 
maintenance.  Red,  Anti-aircraft  weapons. 

Scope  of  Conflict:  Conventional  warfare. 

Mission  Area:  All  conventional  missions. 


Level  of  Detail  of  Processes  and  Entities:  The  blue  aircraft 
are  modeled  individually  against  red  anti-aircraft  installations 
in  the  grid  area  that  are  performing  various  mission  profiles 
including  attack,  contact,  utility  and  recovery  missions.  All 
divisional  units  involved  in  operating  and  maintaining  helicopter 
operations . 

CONSTRUCTION: 

Human  Participation:  Required  for  data  formatting  and  database 
construction.  Not  required  during  simulation. 

Time  Processing:  Event  stepped  model. 

Treatment  of  Randomness:  Air  attrition  stochastically  based  on 
direct  computation  of  probability  of  detection  and  probability  of 
kill . 
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Sidedness :  Two-Sided,  both  sides  reactive  but  asymmetric. 


LIMITATIONS :  Dependent  on  external  data,  and  maintenance  systems 

are  not  subject  to  attack. 

INPUT:  RAM  data  for  systems  of  interest,  combat  damage  over 

time,  mission  profiles  over  time,  maintenance  organizations , and 
ALDT  for  parts . 


OUTPUT :  Computer  printouts  containing  charts  of  operational 

availability,  parts  required,  system  failures,  and  maintenance 
manpower  requirement's. 


HARDWARE  AND  SOFTWARE: 
Computer  (OS):  UNI VAC 
Storage : 46 , 00C  Tracks. 
Peripherals :  Printer. 

Programming  Language : 
Documentation :  TRASANA 
Aircraft  Reliability  and 
II  User's  Manual. 


1100,  VAX  11/780. 

Changes  depending  on  scenario  used. 
SIMSCRIPT,  FORTRAN. 

Model  Description  Document  and  TRASANA 
Maintainability  Simulation-CAA  Version 


SECURITY  CLASSIFICATION;  UNCLASSIFIED. 

GENERAL  DATA: 

Time  P.eguirements :  24  weeks  for  preparation,  run  and  analysis. 

CPU  Time  per  Cycle:  Changes  depending  on  size  of  scenario 
used.  2-20  hours. 

Freguencv  of  Use:  Sporadic. 


Users :  DCSLOG,  AVNC,  CAA,  Transportation  School. 

Releasabil itv :  Releasable. 


Comments :  Original  version  called  TARMS  was  developed  by  RAIL 

Corporation  for  TRASANA  in  1978  and  was  written  in  GPSS.  TRASANA 
converted  the  model  to  SIMSCRIPT.  In  1982,  the  model  was 
transported  from  TRASANA  to  the  US  Army  Concepts  Analysis  Agency 
(CAA)  for  use  in  support  of  the  Maximizing  Daily  Helicopter 
Flying  Hours  (MAX  FLY)  Study.  At  that  time,  the  portions  of  the 
model  that  represented  combat  damage  inflicted  by  threat  weapon 
systems  underwent  extensive  modification  to  allow  consideration 
of  damage  caused  by  missile  systems  with  proximi ty- fused 
warheads.  Upon  completion  of  the  MAX  FLY  Study,  TARMS  was 
further  modified  and  expanded  by  CAA  to  its  present  form, 

TARMS- I I .  These  modifications  include: 

•  The  capability  to  evaluate  different  repair  parts 
acquisition  policies  (i.e.,  cross- le  s/el  ing  )  . 
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•  Modification  of  doctrine  relevant  to  attack/scout  helicopter 
mixes  for  attack  missions. 

•  The  inclusion  of  an  artificial  intelligence  package  to  allow 
selection  of  alternate  flight  profiles,  or  a  decision  not  to  fly 
specific  missions  based  on  experienced  attrition  rates. 

•  The  inclusion  of  dynamic  prescribed  load  list/authorized 
stockage  list  (PLL/ASL)  modifications  emulating  the  provisions  of 
Army  Regulation  ( AR )  710-2. 
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TITLE :  Vector- in  Cartnander  (VIC) 
MODEL  TYPE:  Analysis 


DATE  IMPLEMENTED:  10/01/90 


PROPONENT:  TRADOC  Analysis  Command  (TRAC),  Operations  Analysis  Center 
(QAC)  Fort  Leavenworth,  Kansas  66027-5200 

POINT  OF  CONTACT:  Mr.  Calkins,  ATRC-FM,  AV:  552-4595 
TRAC-QAC,  Fort  Leavenworth,  KS  66027-5200 

PURPOSE:  VIC  is  a  ccnputerized,  analytical,  mid- intensity  model  developed 
for  use  in  estimating  net  assessments,  performing  force  deployment 
studies,  and  generating  information  for  performing  trade-offs  among  weapon 
the  outcome  of  force  interactions  is  determined  in  terms  of  the  ground 
gained  or  lost  and  the  attritions  of  personnel  and  weapon  systems. 

DESCRIPTION :  The  VIC  model  is  a  two-sided,  deterministic  simulation  of 
integrated  land  and  air  combat.  The  level  of  aggregation  is  the  maneuver 
battalion  or  its  equivalent.  It  employs  forces  up  to  the  level  of  a  U.S. 
corps  facing  an  enemy  of  strength  determined  by  scenario  and  theater  in 
which  the  simulation  takes  place.  VIC  is  an  event-stepped  model  which 
also  employs  time  steps  for  scheduling  seme  actions.  It  uses  modified 
differential  equations  for  combat  outcomes  based  upon  the  VECTOR- 2  model. 
Tactical  decisions  and  force  employments  are  determined  by  tactical 
decision  tables  supplied  by  the  user  to  provide  flexibility  in  controlling 
model  processes.  Each  side  may  employ  maneuver  unit  weapon  systems  and 
weapons  to  tactical  aircraft,  as  well  as  artillery,  mines,  helicopters, 
air  defense  systems,  and  other  means  of  conducting  combat  at  the  U.  S. 
Corps  Level. 

OCNSTRUCTICN:  VIC  is  a  two  sided  model  requiring  no  human  participation 
once  the  data  bases  are  constructed.  The  model  can  be  interrupted  if 
desired  by  the  user.  It  is  deterministic  with  a  dynamic  architecture  that 
is  event  driven. 

LIMITATIONS :  TBD 

INPUT: 

-  Forces  and  supply  inventories 

-  Basic  weapons  performance  data 

-  Other  system  performance  data 

-  Geographic  and  terrain  data 

-  Tactical  decision  tables 

OUTPUT: 

-  Casualties  and  system  losses  (killer/ victim  scoreboards,  etc) 

-  Flot  traces  and  force  positions  overtime 

-  Target  acquisition  and  intelligence  sunmaries 

-  Availability  and  condition  of  forces  and  supplies 

-  Air  battle  and  air  defense  results 

HARDWARE  AND  SOFTWARE: 

COMPUTER  (OS)  :  VMS 
STORAGE:  800,000  Blocks 
PERIPHERALS:  None 
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PROGRAMING  LANGUAGE:  SUBSCRIPT  &  FORTRAN 

DOCUMENTATION:  VIC  Data  Input  &  Methodology  Manual 
VIC  Executive  Summary 
VIC  Postprocessor  User  Guide 

SECURITY  CLASSIFICATION :  UNCLASSIFIED 

GENERAL  DATA  AND  TIME  REQUIREMENTS: 

DATABASE:  2  Weeks 

CPU  TIME  PER  CYCLE:  4  Hour  CPU/4  Hours  battle  time 
FREQUENCY  OF  USE:  Weekly  at  TRAC 
USERS:  TRAC,  AMSAA,  CAA,  RAND 

COMMENTS:  Government  agencies  can  obtain  VIC  with  a  signed  memorandum 
of  agreement.  Government  Contractors  with  a  valid  contract  requiring  the 
use  of  VIC  can  also  obtain  the  model  with  the  approval  of  the  TRAC 
Commanding  General .  Inquiries  for  obtaining  the  model  and  supporting  data 
bases  should  be  addressed  to  TRAC -TOD,  Ft.  Leavenworth,  KS  66027-5200  or 
call  AV  552-551 1  or  commercial  91 3-684-551 1 . 
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TITLE :  Vehicle  Gap  Crossing  Under  Fire  Simulation  -  VGCUFS 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.S.  Army  Materiel  Systems  Analysis  Activity. 

POINT  OF  CONTACT:  Director,  USAMSAA,  ATTN:  AMXSY-CM  (L.  Martin) 
Aberdeen  Proving  Ground,  MD  21005-5071,  AV  298-6437/(301)278-6437 

PURPOSE :  A  research  and  evaluation  tool  used  at  the  item  level. 

VGCUFS  offers  a  means  of  assessing  the  effect  a  vehicle's 
automotive  performance,  or  changes  in  vehicle  parameters  such  as 
engine  performance  or  weight,  have  on  its  survivability  on  the 
battlefield.  The  effect  of  specific  terrain  on  the  target 
vehicle-weapon  encounter  can  also  be  examined. 

DESCRIPTION: 

Domain :  Land. 

Span :  Individual. 

Environment :  Terrain  mobility  characteristics. 

Force  Composition:  Individual  element. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Survivability  to  direct  fire. 

Level  of  Detail  of  Processes  and  Entities: 

Entity :  Individual  vehicle. 

Processes :  Mobility,  survivability. 

CONSTRUCTION: 

Human  Participation:  Not  permitted. 

Time  Processing:  Dynamic,  time  step. 

Treatment  of  Randomness:  Stochastic,  direct  computation  for 
decision  on  existence  of  line-of-sight;  remainder  deterministic. 

Sidedness :  One-sided. 

LIMITATIONS :  One  weapon  firing  at  one  target.  The  target  does 

not  return  fire. 

PLANNED  IMPROVEMENTS/MODIFICATIONS :  Analytical  determination  of 
the  existence  of  line-of-sight  using  terrain  elevation  data  will 
replace  the  statistical  method  currently  in  use.  Vehicle 
performance  along  its  path  of  travel  will  be  simulated  using  the 
Army  Mobility  Model,  replacing  the  current  acceleration  method. 


INPUT :  Target  vehicle  data  required  are  weight,  power  train  and 

traction  characteristics.  Terrain  data  required  include  surface 
slope,  mean  'in  view'  segment  length,  mean  'out  of  view'  segment 
length,  and  mean  first  opening  range.  Opposing  weapon  data 
required  are  horizontal  and  vertical  bias  and  dispersion  as  a 
function  of  range  and  target  speed,  time  to  first  shot,  and  time 
to  subsequent  shots.  The  target  is  described  by  a  two  rectangle 
fit  of  the  target  at  the  angle  of  attack  being  simulated,  and 
range  to  target  at  start  time. 

OUTPUT :  Graphs  and  tables  give  probability  of  each  shot  hitting 

the  vehicle  and  elapsed  time,  distance  traveled,  range,  and 
vehicle  speed  at  shot  time.  Probability  that  the  vehicle  can 
cross  the  'in  view'  segments  and  not  be  hit  is  also  tabulated  and 
plotted . 

HARDWARE  AND  SOFTWARE: 

Computer  (OS):  Cray-XMP  (UNIX). 

Storage  required:  Main  program  -  91594  bytes;  Pre/post 
processors  -  26300  bytes. 

Peripherals :  1  printer,  1  color  graphics  copier. 

Programming  Language;  FORTRAN. 

Documentation :  AMSAA  CSD  Interim  Note  No.  C-151. 

SECURITY  CLASSIFICATION:  (Model  without  data)  UNCLASSIFIED. 
GENERAL  DATA: 

Database ;  (time  required  to  prepare)  Many  weapons  and  vehicles 
now  reside  in  the  data  base.  Additional  weapons  and/or  vehicles 
can  be  added  in  a  few  hours  if  performance  data  are  available. 

CPU  Time  per  Cycle:  1.94  seconds  for  one  replication  of  the 
model  running  one  vehicle/weapon  combination. 

Data  Output  Analysis:  (time  required)  Analysis  of  graphical 
and  tabular  output  required  minimal  effort.  For  a  typical  run  of 
two  weapons  against  three  vehicles  a  maximum  of  1 0  minutes  is 
required . 
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TITLE ;  War  Reserves  for  Combat  Damage 
DATE  IMPLEMENTED:  1988. 

MODEL  TYPE:  Analysis. 

PROPONENT :  U.S.  Army  Materiel  Systems  Analysis  Activity. 

POINT  OF  CONTACT:  Stan  Butler,  DSN  298-4932,  and  Elaine 
Sadofsky,  DSN  298-4980. 

PURPOSE:  The  War  Reserves  for  Combat  Damage  Model  is  used  to 

predict  Class  IX  replacement  parts  requirements  rates  for  combat 
damaged  fighting  systems.  The  replacement  rates  are  obtained  by 
applying  shotline  damage  probabilities  to  end  item  expected 
combat  damage  incidents  categorized  by  threat  weapon,  range,  and 
exposure  condition.  The  model  serves  as  a  link  between  the  U.S. 
Army  Concepts  Analysis  Agency's  Concepts  Evaluation  Model  and 
Sustainability  Predictions  for  Army  Spare  Component  Requirements 
for  Combat  (SPARC)  databases.  The  resulting  predicted 
requirements  rates  are  used  in  the  yearly  Class  IX  war  reserves 
calculations  by  the  Major  Subordinate  Commands. 

DESCRIPTION: 

Domain:  Land  and  air. 

Span :  Theater-level  requirements. 

Environment :  N/A. 

Force  Composition:  N/A. 

Scope  of  Conflict:  Conventional. 

Mission  Area:  Direct  and  indirect  fire  threat  weapons  damage. 

Level  of  Detail  of  Processes  and  Entities: 

Entities :  modelled  down  to  the  Line  Replaceable  Unit  (LRU). 

CONSTRUCTION: 

Human  Participation:  Required  for  decisions. 

Time  Processing:  Static. 

Treatment  of  Randomness:  Deterministic. 


Sidedness :  One-sided. 

LIMITATIONS :  Considers  only  primary  damage  mechanisms  such  as 

high-explosive  fragmentation,  main  penetrator,  and  spall  damage. 
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Does  not  consider  secondary  damage  mechanisms  such  as  mechanical 
shock  due  t'-'  non-penetrating  hits  and  fire  propagation  due  to 
electrical  shorts. 

PLANNED  IMPROVEMENTS  AND  MODIFICATIONS:  Vertical  shotlines  for 
top  attack  type  threats  are  being  developed  for  selected 
high-value  fighting  systems. 

INPUT:  Processed  scenario  information  along  with  the  SPARC 

database  for  a  fighting  system  of  interest. 

OUTPUT :  Output  produced  for  a  fighting  system  consists  of  combat 

damage  factors  for  each  component.  The  combat  damage  factors 
consist  of  Failure  Factor  Four  (FFIV)  and  two  combat  intensity 
scaling  factors  tailored  for  the  MSC's  War  Reserves  Automated 
Process  (WRAP). 

HARDWARE  AND  SOFTWARE: 

Computer :  Recently  transferred  to  a  SING  computer  with  a  UNIX 

operating  system. 

Storage :  290Mb  required  for  storage  of  current  databases. 

Peripherals :  Requires  secure  and/or  encrypted  computing 

environment  (see  "SECURITY  CLASSIFICATION"  below). 

Programming  Language:  FORTRAN,  INGRES. 

Documentation :  Not  extensively  documented. 

SECURITY  CLASSIFICATION:  Programs  UNCLASSIFIED,  but  databases 
are  classified  up  to  the  SECRET  level. 

GENERAL  DATA: 

Data  Base:  Development  of  a  SPARC  database  for  a  fighting 
system  can  take  2-4  man-years,  depending  upon  the  complexity  of 
the  system  and  its  vulnerability  target  description.  The  data 
and  programs  are  considered  to  be  not  portable. 

CPU  Time  per  Cycle:  N/A. 

Data  Output  Analysis:  Postprocessors  aide  in  the  task  of 
converting  the  outputs  to  formats  required  for  various 
applications . 

Freguencv  of  Use:  Several  times  per  year  in  support  of 
processes  such  as  Class  IX  War  Reserves,  Standardized  Combat 
Authorized  Stockage  List/Prescribed  Load  List,  etc. 

Users :  Due  to  portability  considerations,  AMSAA  is  the  only 

hands-on  user  of  the  SPARC  databases  and  programs. 

Releasabilitv :  N/A. 
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TITLE :  Weapon  Effectiveness  Battle  Simulation  -  WEBS 

DATE  IMPLEMENTED:  1981. 

MODEL  TYPE:  Analysis. 

PROPONENT :  CA4  Division,  RARDE,  Fort  Halstead,  Sevenoaks,  Kent, 

England . 

POINT  OF  CONTACT:  P.  R.  Syms,  RARDE,  ext  2452. 

PURPOSE :  Evaluation  of  Direct  Fire  land  systems  at  the 

battlegroup  (battalion)  level. 

DESCRIPTION: 

Domain :  Land. 

Span :  Local,  tactical. 

Environment :  Stochastic  terrain,  using  statistics  gathered 

from  runs  of  BGWG  (q.v.)  and  (in  near  future)  JANUS /BGWG  (q.v.). 

Composition  Scope:  Heterogeneous  mechanized  forces. 

Mission  Area:  Direct  fire  battle.  Typically,  a  10km  front. 

Level  of  Detail:  Individual  vehicles  and  GW  teams  represented. 

CONSTRUCTION : 

Human  Participation :  None . 

Time  Processing:  Event  sequenced. 

Treatment  of  Randomness:  Stochastic. 

Sidedness :  Two-sided,  fully  symmetric. 

LIMITATIONS :  Limited  ability  to  update  tactics  during  a  run.  No 

ability  to  represent  infantry,  barriers  or  fixed  wing  aircraft. 
Terrain  and  routes  are  represented  in  a  abstract  manner,  such 
that  movement  routes  are  constrained  to  East-West  and  North- 
South.  No  theoretical  limit  on  unit  numbers,  but  practically  120 
Blue/300  Red. 

PLANNED  IMPROVEMENTS :  Ability  to  transfer  scenarios  from 
JANUS /BGWG.  Also  minor  model  changes  planned  to  some  areas 
including  target  selection. 

INPUT :  Vehicles  and  weapon  characteristics;  Minefields  and 

artillery  mission  data;  Orbat,  deployment,  orders  and  tactics; 
Probability  data. 
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OUTPUT :  Killer/Victim  tables,  by  replication  and  averaged; 

Firer/Target  tables,  by  replication  and  averaged;  Individual 
events  on  request. 

HARDWARE  AND  SOFTWARE : 

Computer /OS :  DEC  11/750  and  6000  series  computers;  VAX/VMS. 
Storage :  Typically  200  blocks  input  data  for  a  battlegroup 
scenario,  6000  blocks  executable  code.  Output  files  anywhere 
from  a  few  blocks  to  20000  blocks,  depending  on  amount  of 
information  requested. 

Peripherals ;  Disc  storage,  line  printer  etc. 

Language :  FORTRAN  77.  Some  utilities  written  in  Pascal. 

Documentation :  4  volumes  (user  &  programmers'  guides,  model 

definitions  and  executive  summary.  Updated  with  model). 

CLASSIFICATION:  Software  is  UNCLASSIFIED. 

GENERAL  DATA: 

Time  Reguired: 

Data  Preparation:  A  few  hours  to  several  weeks. 
Preprocessor :  None . 

Simulation :  areal  time;  highly  dependent  on  machine  and 

battle  size. 

Analysis  Package:  Yes. 

Freguencv  of  Use:  In  constant  use.  (Has  experienced  a 
renaissance  sine  simulation  data  last  collect.) 

Users :  CA4  RARDE.  TRAC-WSMR  and  AMSAA  ( APG)  have  older 

versions;  it  is  unknown  what  use  they  make  of  them.  DSc(L)  MOD 
will  possibly  be  using  WEBS  in  the  near  future  in  place  of  SLEW 
(q. v.  )  . 
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